Message-ID: <CALiw-2GWHKPbXuMFXUHY_pgpUJNdqQbyPEV1UjEep3zD2sSRPQ@mail.gmail.com>
Date:	Mon, 16 Jun 2014 09:39:07 -0700
From:	Olof Johansson <olofj@...omium.org>
To:	Julius Werner <jwerner@...omium.org>
Cc:	Rob Herring <robherring2@...il.com>,
	Rob Herring <robh+dt@...nel.org>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	Stephen Warren <stephen.r.warren@...il.com>,
	Doug Anderson <dianders@...omium.org>,
	Stefan Reinauer <stefan.reinauer@...eboot.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] firmware: Add device tree binding for coreboot

2014-06-13 14:58 GMT-07:00 Julius Werner <jwerner@...omium.org>:
>> This is just to export a fixed log to userspace (like a DMI table) or
>> the kernel will actually use the data in some way? Based on the link,
>> it looks like the former to me.
>
> I could imagine both. The link is an in-kernel driver that exposes a
> log through a sysfs node (in a way that has already been established
> on x86 systems, which find the location through EBDA or ACPI entries
> instead). We are also using a user-space tool that reads the address
> from /proc/device-tree and accesses it through /dev/mem. The areas can
> contain many interesting entries (like the location of an early
> framebuffer set up by the firmware), so I could also imagine use cases
> where the kernel makes use of it directly.

Hmm. It'd be much better if the early framebuffer was communicated
using the already existing methods (i.e. simplefb device tree node).
That way we don't have to add custom code to grab it out of the
coreboot memory structure.

Adding a platform driver for coreboot to do it later in boot isn't so
hard (and registering platform devices based on the contents), but we
probably need to be more generic if it is to be used in actual early
boot, which is the main use case for it.

>> Don't you need need to keep the kernel from allocating this memory by
>> using one of the reserved memory mechanisms? The recently added one
>> should be able to specific what the memory is reserved for IIRC.
>
> Our bootloader is carving the location out of the /memory node and
> adding it to the device tree reserve map. As far as I know, that only
> contains a list of raw start and size entries. At any rate, I think
> it's useful (and in line with other bindings) to add a more explicit
> node like this (if only to make it easier accessible through
> /proc/device-tree).
>
>> /firmware is already used IIRC. What if you have other firmware such
>> as Trustzone?
>
> I'm not quite sure how Trusted Foundations works and whether it would
> even make sense to use it in parallel to coreboot, but it seems to be
> using the /firmware/trusted-foundations subnode so that should be
> fine. "firmware" seems to be used by other firmware implementations
> (like "samsung,secure-firmware") which are similar in nature to and
> mutually exclusive with coreboot, so I thought the node makes sense.
> (The kernel should use the compatible string to find it anyway, so a
> future name clash would not be world-ending.)

Right, coreboot really should go under /firmware/coreboot -- we
already use /firmware/chromeos on chromebooks to specify
chromeos-specific firmware properties, this follows that convention.

The samsung,secure-firmware should probably also be moved to a
subnode. The binding shouldn't require a specific location no matter
what.


-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists