VPD not showing up in sysfs

[Nathan]

It looks like there's a driver in the kernel for CrOS VPD that is meant to populate sysfs with VPD. Unfortunately, on every system I've tested this is not working.

When I check the syslog, I get "platform vpd: Driver vpd requests probe deferral".

Anyone else see the same thing? Ideas for how I can fix it?

[Julius Werner]

Please be more specific which platforms you're talking about. The
sysfs VPD interface is a relatively new addition and doesn't exist on
devices 2015 and earlier. Even if the driver is enabled in the kernel
for a particular platform, it may be that system firmware for that
platform does not support it (and then you'd see a message like the
one you copied).

Also, please confirm that you actually have a VPD. The VPD is stored
on the firmware SPI flash, and if you manually reflash firmware a lot
it's easy to loose it if you're not careful. You can check with the
'vpd -l' command.

> --
> --
> Chromium OS Developers mailing list: chromiu...@chromium.org
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en
>

[Julius Werner]

edit: Also, running the 'cbmem -l | grep VPD' command should be a
quick way to check if system firmware supports the VPD interface, but
the command might not be available on all platforms.

[David Hendricks]

As Julius pointed out, the sysfs VPD interface is relatively new and not supported on all platforms. The supported way to obtain VPD info is using the "vpd" utility which will try to use sysfs first and then fallback to reading the ROM via flashrom if needed.

---
You received this message because you are subscribed to the Google Groups "Chromium OS dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-os-dev+unsubscribe@chromium.org.

--

David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.

[Hung-Te Lin]

2017-01-19 9:35 GMT+08:00 'David Hendricks' via Chromium OS dev <chromiu...@chromium.org>:

As Julius pointed out, the sysfs VPD interface is relatively new and not supported on all platforms.

    To be more specific, you probably can find it on ARM Chromebooks running kernel 3.18+, or x86 Chromebooks running kernel 4.4+.

 

The supported way to obtain VPD info is using the "vpd" utility which will try to use sysfs first and then fallback to reading the ROM via flashrom if needed.

    I think you're referring to the script "vpd_get_value" which will try sysfs first then lookup the cache from dump_vpd_log.

    'vpd' will always read via flashrom, while sysfs will be updated only after system reboot.

[Nathan]

If there weren't any VPD on the system, I would still expect sysfs to have ro and rw subdirs and to not emit the probe message. Is this expectation reasonable?

I tried on a number of systems, new and old. I tried on a ultima system running a stock ChromeOS image (3.18 kernel; vpd -l emits some vpd data but the sysfs is empty) and a pbody system running a custom ChromiumOS build I made (for some reason this is also a 3.18 kernel; vpd is empty). I also just tried it on a samus system I have lying around, but that's a 3.14 kernel so the vpd driver isn't even present.

Based on what Hung-Te Lin says, it sounds like I shouldn't expect it to work because these are all x64 platforms running 3.18.

Apparently I don't quite understand how the vpd driver works, because I don't understand why a kernel which has it built in would not be able to load it. But it sounds like, whatever the reason, I am up a creek when it comes to using the sysfs interface.

Is there anything I can do, or am I just out of luck?

Nathan

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-os-d...@chromium.org.

[David Hendricks]

On Thu, Jan 19, 2017 at 2:26 AM, Hung-Te Lin <hun...@chromium.org> wrote:

2017-01-19 9:35 GMT+08:00 'David Hendricks' via Chromium OS dev <chromiu...@chromium.org>:

The supported way to obtain VPD info is using the "vpd" utility which will try to use sysfs first and then fallback to reading the ROM via flashrom if needed.

    I think you're referring to the script "vpd_get_value" which will try sysfs first then lookup the cache from dump_vpd_log.

    'vpd' will always read via flashrom, while sysfs will be updated only after system reboot.

Yes, thanks Hung-Te :-)

[David Hendricks]

[+wnhuang who wrote the driver]

On Thu, Jan 19, 2017 at 6:31 AM, Nathan <nat...@lenovo-chrome.com> wrote:

If there weren't any VPD on the system, I would still expect sysfs to have ro and rw subdirs and to not emit the probe message. Is this expectation reasonable?

The driver currently errs out before creating those sub-directories if either the coreboot table entry is missing (not supported by firmware) or if the magic number in the header isn't right (VPD could be missing or corrupted): https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.4/drivers/firmware/google/vpd.c#207

If you need the subdirectories to be created regardless, perhaps that could be done via a feature request.

Is there anything I can do, or am I just out of luck?

If you're building a custom firmware ROM then you can add the necessary cbmem support. Otherwise, yeah, you're kinda out of luck with using sysfs on those unsupported systems :-/

It would help to know your use case a little better. Maybe you can use vpd_get_value or read cached values from /mnt/stateful_partition/unencrypted/cache/vpd?

[Brian Norris]

The probe deferral message should be dev_dbg() on semi-recent kernels (>=4.1) [1], since it's known to be annoying/noisy; in a fully working system, you might still expect to see several deferrals. So if you're worrying about log spamminess, then we should make sure that's working. I suspect we could even backport it to 3.14/3.18 if needed.

This driver also seems a little weird, because it looks like coreboot_table_find() will return -EPROBE_DEFER indefinitely, even after it knows it can't find any coreboot tables. Seems like there's room for improvement there.

Brian

[1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=13fcffbbdec4e4863a9a9c7792b821cd6d363a8f
driver core: Make probe deferral more quiet

--

[Julius Werner]

> This driver also seems a little weird, because it looks like
> coreboot_table_find() will return -EPROBE_DEFER indefinitely, even after it
> knows it can't find any coreboot tables. Seems like there's room for
> improvement there.

It needs to defer probing because the base address it's using is put
in by another driver. Isn't that the intended way of dealing with
driver dependencies like this? Also, I thought the driver core has
some code to prevent indefinite re-probing (like, it keeps trying to
probe the list of all still deferring drivers, but once it does a pass
where not a single new driver probed successfully it stops), or am I
misremembering that?

[Nathan]

David,

Thanks for your input! I believe reading cached values from the stateful partition will address our use case, as the particular VPD element we're reading is RO and is not expected to change. I'll explore that as a possibility for the moment.

We are writing a userspace driver which needs to reference VPD data on load, and we didn't want to take the latency hit of calling flashrom (as the command-line vpd program does) in order to read the data from coreboot.

We are actually building, as you suggest, a custom firmware for our particular platform. Can you elaborate on adding the necessary cbmem support? Sorry if this should be obvious; I'm still kind of finding my way in the CrOS ecosystem.

I appreciate your help!

Nathan

[Brian Norris]

On Thu, Jan 19, 2017 at 12:53 PM, Julius Werner <jwe...@chromium.org> wrote:

> This driver also seems a little weird, because it looks like
> coreboot_table_find() will return -EPROBE_DEFER indefinitely, even after it
> knows it can't find any coreboot tables. Seems like there's room for
> improvement there.

It needs to defer probing because the base address it's using is put
in by another driver. Isn't that the intended way of dealing with
driver dependencies like this?

Yes, more or less. But I'm not sure the device instantiation here actually makes sense, and so probe deferral isn't really the right mechanism. For instance, it's not typically expected to unconditionally register a device at module init time like this:

static int __init platform_vpd_init(void)

{

        struct platform_device *pdev;

        pdev = platform_device_register_simple("vpd", -1, NULL, 0);

        if (pdev == NULL)

                return -ENODEV;

...

Instead, it seems like the kind of device that should get instantiated from within the coreboot driver.

(FWIW, I doubt the current driver would be upstreamable with the above code.)

 

Also, I thought the driver core has
some code to prevent indefinite re-probing (like, it keeps trying to
probe the list of all still deferring drivers, but once it does a pass
where not a single new driver probed successfully it stops), or am I
misremembering that?

Yes, I believe it relies on the addition of some probed device. If no new device manages to probe successfully, then there's no way to satisfy a deferred device. But the deferred device still stays on the list and gets reprobed every time a new device probes. That could be one of various hotpluggable devices (e.g., USB), I think.

It's not a big deal, but I was just suggesting that it's possible to stop deferring once a coreboot "provider" (either the OF or ACPI driver) registers, and can't find any tables. At that point, it's something like -ENODEV, not -EPROBE_DEFER. But maybe that's not a great idea, and I actually think there are better ways of implementing this that don't involve probe deferral.

Regardless, I gather that Nathan is interested in actually *using* the VPD, not just explaining why the logs are complaining about it.

Brian

[Julius Werner]

> Instead, it seems like the kind of device that should get instantiated from within the coreboot driver.

I'm not quite sure I follow. Are you saying that coreboot.c should
call something that instantiates the VPD driver?

One of the design goals of this is that VPD, CBMEM console and other
features can be enabled/disabled independently in Kconfig. The
"coreboot" driver is just a service that provides access to a shared
resource they all need (the coreboot tables) and gets pulled in
automatically as a dependency if any of these are enabled. I think
this model couldn't be supported by what you're suggesting (unless you
want to put an unscalable amount of #ifdefs in the function that would
instantiate the dependent drivers).

> It's not a big deal, but I was just suggesting that it's possible to stop deferring once a coreboot "provider" (either the OF or ACPI driver) registers, and can't find any tables. At that point, it's something like -ENODEV, not -EPROBE_DEFER. But maybe that's not a great idea, and I actually think there are better ways of implementing this that don't involve probe deferral.

I think there might be situations where you have more than one
provider enabled and can't be quite sure which one will work, so this
isn't that easy.

> We are actually building, as you suggest, a custom firmware for our particular platform. Can you elaborate on adding the necessary cbmem support? Sorry if this should be obvious; I'm still kind of finding my way in the CrOS ecosystem.

What platform exactly is this? An existing official Chrome OS device?
Just a random PC running Chromium OS? Or some unreleased future
platform (if so, are you planning to develop it with Google as an
official Chrome OS device or an unofficial Chromium OS port)?

Any future official device built with Google should include the
interface. We mandate the use of our coreboot-based firmware on all
devices, and this feature has landed in coreboot's master branch a
while ago, so any future fork will have it.

If you're building an unofficial port totally by yourself, it very
much depends on what you're doing. The sysfs interface is directly
tied to data structures specific to coreboot, so if your firmware is
not coreboot-based it won't work (you could of course try to emulate
that interface, but at that point it's probably easier to just write a
new driver yourself). If you are using coreboot, any relatively recent
fork will have it (part of the CONFIG_CHROMEOS option).

[Brian Norris]

On Thu, Jan 19, 2017 at 2:44 PM, Julius Werner <jwe...@chromium.org> wrote:

> Instead, it seems like the kind of device that should get instantiated from within the coreboot driver.

I'm not quite sure I follow. Are you saying that coreboot.c should
call something that instantiates the VPD driver?

You could, for instance, move this code to coreboot_table_init():

         pdev = platform_device_register_simple("vpd", -1, NULL, 0);

        if (pdev == NULL)

                return -ENODEV;

No #ifdefs required. It just won't bind to a driver if that driver is compiled out.

There's similar structure for cros-ec (and other MFDs (Multi Function Devices)). See how ec_device_probe() checks for various EC features before instantiating sub-devices which attach to their own drivers.

Brian

[Daniel Kurtz]

Hi Julius,

On Fri, Jan 20, 2017 at 6:44 AM, Julius Werner <jwe...@chromium.org> wrote:

> Instead, it seems like the kind of device that should get instantiated from within the coreboot driver.

I'm not quite sure I follow. Are you saying that coreboot.c should
call something that instantiates the VPD driver?

One of the design goals of this is that VPD, CBMEM console and other
features can be enabled/disabled independently in Kconfig. The
"coreboot" driver is just a service that provides access to a shared
resource they all need (the coreboot tables) and gets pulled in
automatically as a dependency if any of these are enabled. I think
this model couldn't be supported by what you're suggesting (unless you
want to put an unscalable amount of #ifdefs in the function that would
instantiate the dependent drivers).

> It's not a big deal, but I was just suggesting that it's possible to stop deferring once a coreboot "provider" (either the OF or ACPI driver) registers, and can't find any tables. At that point, it's something like -ENODEV, not -EPROBE_DEFER. But maybe that's not a great idea, and I actually think there are better ways of implementing this that don't involve probe deferral.

I think there might be situations where you have more than one
provider enabled and can't be quite sure which one will work, so this
isn't that easy.

> We are actually building, as you suggest, a custom firmware for our particular platform. Can you elaborate on adding the necessary cbmem support? Sorry if this should be obvious; I'm still kind of finding my way in the CrOS ecosystem.

What platform exactly is this? An existing official Chrome OS device?
Just a random PC running Chromium OS? Or some unreleased future
platform (if so, are you planning to develop it with Google as an
official Chrome OS device or an unofficial Chromium OS port)?

As mentioned earlier in the thread, Nathan is using pbody.

Any future official device built with Google should include the
interface. We mandate the use of our coreboot-based firmware on all
devices, and this feature has landed in coreboot's master branch a
while ago, so any future fork will have it.

pbody's coreboot is using the cros/firmware-glados-7820.B branch.

If you're building an unofficial port totally by yourself, it very
much depends on what you're doing. The sysfs interface is directly
tied to data structures specific to coreboot, so if your firmware is
not coreboot-based it won't work (you could of course try to emulate
that interface, but at that point it's probably easier to just write a
new driver yourself). If you are using coreboot, any relatively recent
fork will have it (part of the CONFIG_CHROMEOS option).

Is it possible this branch is too old to have the CONFIG_CHROMEOS option?

If so, which patches should be backported to this branch?

[Hung-Te Lin]

+dlaurie

The VPD via Coreboot support has been merged recently to glados fw branch by Duncan ( https://chromium-review.googlesource.com/#/c/431798/ ).

If you build a new firmware then VPD should be available using ToT 3.18 kernel.

---
You received this message because you are subscribed to the Google Groups "Chromium OS dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-os-dev+unsubscribe@chromium.org.

[Nathan]

Duncan and I had a conversation off-list. Even with his patches, the VPD sysfs interface does not work with the 3.18 kernel. Unfortunately, neither of us have had the bandwidth to figure out why. I'm currently using the VPD cache, which is sufficient for my purposes.

It's possible at some point I'll have the time to loop back around and do the debugging required to figure out what's going wrong with the driver, but that's a pretty low priority at the moment.

Thanks!

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-os-d...@chromium.org.