On Thu, 20 Feb 2025 13:27:25 +0100, Michal Simek wrote:
> Describe TI TPS5381 a dual-channel multiphase step-down controller
> supporting per-phase and per-channel output telemetry.
>
> Signed-off-by: Michal Simek
> ---
>
> Linux kernel driver support has been added by commit 53030bcc87e4 ("hw
cation of the properties?
I always feel better if we have multiple users for a new, common
binding. A new binding extended by a 2nd user shortly after defining
it makes me grumpy. Here's a thread that came up with the same type of
issue:
https://lore.kernel.org/all/20250113112349.801875-1-prabhakar.mahadev-lad...@bp.renesas.com/
> Would you prefer a patch to the spec and discuss "code" directly there?
Generally, anything new is schema first. Ideally the spec would get
generated from schemas, but there's no work being done on that.
Rob
utils/dtc/dtc.git, so the patch should be
> > rebased against it and sent to devicetree-compi...@vger.kernel.org.
>
> Looks like someone independently fixed it upstream:
> https://github.com/dgibson/dtc/pull/154
>
> I'm doing final tests now and expect to merge shortly.
Would be good to tag a release too, so that distros have something to
pick up when they update swig.
Rob
(-)
> rename Documentation/devicetree/bindings/nvmem/{ => layouts}/u-boot,env.yaml
> (75%)
>
Reviewed-by: Rob Herring (Arm)
; Changes in v2:
> - Use plain partition@xxx for the node name
>
> .../bindings/mtd/partitions/binman.yaml | 53 +++
> .../bindings/mtd/partitions/partition.yaml| 21 ++++
> MAINTAINERS | 5 ++
> 3 files changed, 79 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/mtd/partitions/binman.yaml
>
Reviewed-by: Rob Herring
On Wed, Jan 31, 2024 at 8:09 PM Masahiro Yamada wrote:
>
> On Thu, Feb 1, 2024 at 7:03 AM Rob Herring wrote:
> >
> > On Tue, Jan 30, 2024 at 3:16 AM Masahiro Yamada
> > wrote:
> > >
> > > On Fri, Jan 26, 2024 at 1:04 AM Simon Glass wrote:
> >
pendency on CONFIG_EFI_ZBOOT
> > > > > > > > - Pick up .dtb files separately from the kernel
> > > > > > > > - Correct pylint too-many-args warning for write_kernel()
> > > > > > > > - Include the kernel image in the file count
> > &g
gt; had already seen a good share of review and testing. And with the
> U-Boot releases being always further away than the next kernel release,
> we could pull fixes still in time. So we could pick the latest -rc (or
> .0 release, whichever is more recent) when the U-Boot merge window
> opens?
That should be mostly fine IMO, but there are the occasional "oops,
let's change/fix the binding before it's released".
Couldn't you pull in the latest rc in the merge window, but only if
the .0 release will happen before the next u-boot release. And then
update from rc to .0 before the u-boot release.
Also, from a quick look at the dts changes during rc releases, they
tend to come in the later rc releases. Probably that's just the
latency of going to sub-arch maintainer->SoC->Linus.
Rob
On Thu, Jan 4, 2024 at 3:54 PM Simon Glass wrote:
>
> Hi Rob,
>
> On Thu, Dec 14, 2023 at 2:09 PM Simon Glass wrote:
> >
> > Hi Rob,
> >
> > On Thu, 14 Dec 2023 at 10:27, Rob Herring wrote:
> > >
> > > On Fri, Dec 08, 2023
still struggle with more complex designs
> documentation.
>
>
> As per Rob's comment I think I see his point and a possible design
> confusion. If you look from a pure DT perspective then "partitions" and
> "nvmem-layout" serve a very similar purpose. Th
e, but is describing the layout of storage
already.
Rob
On Thu, Dec 28, 2023 at 4:59 AM Sumit Garg wrote:
>
> Encourage SoC/board maintainers to migrate to using devicetree-rebasing
> subtree and maintain a regular sync with Linux kernel devicetree files
> and bindings.
>
> Along with that add documentation regarding how to run DT bindings
> schema che
; >
> > > -Original Message-
> > > From: Ard Biesheuvel
> > > Sent: Thursday, December 21, 2023 6:31 AM
> > > To: Chiu, Chasel
> > > Cc: Simon Glass ; devicet...@vger.kernel.org; Mark
> > > Rutland
> > > ; Rob Herring ; Tan
On Mon, 18 Dec 2023 14:37:19 +0100, Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> U-Boot env data is a way of storing firmware variables. It's a format
> that can be used of top of various storage devices. Its binding should
> be an NVMEM layout instead of a standalone device.
>
> This patch
iver for the provider and waits for the dependency. Of
course, older kernels don't have that provider driver and so the
dependency is never met. Not sure if u-boot will have similar issues?
At least you should/could know if the provider driver exists or not.
(The kernel doesn't because modules.)
Rob
On Fri, Dec 08, 2023 at 03:58:10PM -0700, Simon Glass wrote:
> Hi Rob,
>
> On Fri, 8 Dec 2023 at 14:56, Rob Herring wrote:
> >
> > On Fri, Dec 8, 2023 at 11:47 AM Simon Glass wrote:
> > >
> > > Hi Rob,
> > >
> > > On Fri, 8 Dec 2023 at
Though it is limited by thinking of what schema changes are
ABI changes and my ability to write python code to parse those cases.
Right now it looks for new required properties, removed properties,
and changed number of entries. I'm interested in any ideas for other
checks.
Rob
[1] https://gitlab.com/robherring/linux-dt/-/jobs
[2] https://github.com/robherring/dt-schema/tree/abi-check
On Fri, Dec 8, 2023 at 11:47 AM Simon Glass wrote:
>
> Hi Rob,
>
> On Fri, 8 Dec 2023 at 08:00, Rob Herring wrote:
> >
> > On Thu, Nov 16, 2023 at 10:28:50AM -0700, Simon Glass wrote:
> > > Add a compatible string for binman, so we can extend fixed
sing is complete, input properties have mostly served their
> + purpose, at least until the firmware is repacked later, e.g. due to a
> + firmware update. The 'fixed-partitions' binding should provide enough
> + information to read the firmware at runtime, including decompression if
> + needed.
How is this going to work exactly? binman reads these nodes and then
writes out 'fixed-partitions' nodes. But then you've lost the binman
specifc parts needed for repacking.
Rob
On Thu, Dec 7, 2023 at 2:08 AM ff wrote:
>
>
>
> > Le 6 déc. 2023 à 21:42, Rob Herring a écrit :
> >
> > On Tue, Dec 5, 2023 at 11:05 PM Sumit Garg wrote:
> >>
> >>> On Tue, 5 Dec 2023 at 15:39, Krzysztof Kozlowski
> >>> wrote:
&
ith devicetree-rebasing instead
(That was the plan at one time) and sync u-boot back to that?
All the work needed to get u-boot and kernel dts files in sync has
virtually no dependency on a standalone repo. If the dts files aren't
already kept in sync, someone has to figure the differences and
eliminate them. Maybe some platforms are in good shape, but it is
still a manual process. Fix that part, because a standalone repo does
nothing for you until you do.
> > > DT bindings alone would ease the compliance process for u-boot drivers
> > > in quite similar manner to Linux drivers.
There's no compliance of drivers really beyond checking if compatible
strings used by drivers have a schema.
Why is extracting the bindings out a problem? SystemReady has no issue
doing just that for its compliance test.
Rob
ally best addressed in Linux by checking the DTS against
> > > yaml DT bindings. We don't have that testing available in u-boot and
> > > only depend on careful reviews.
> >
> > I would absolutely love for someone to make another attempt at updating
> > our kbuild infrastucture so that we can run the validation targets.
> >
>
> Given that EBBR requires [1] the platform (firmware/bootloader) and
> not OS to supply the devicetree, it becomes evident that
> firmware/bootloaders import DTS from Linux kernel (where it is
> maintained).
>
> But currently u-boot doesn't have a proper way to validate those DTS
> against DT bindings (maintained in Linux kernel). Although there are
> Devicetree schema tools available here [2], there isn't a versioned
> release package of DT bindings which one should use to validate DTS
> files.
>
> @DT bindings maintainers,
>
> Given the ease of maintenance of DT bindings within Linux kernel
> source tree, I don't have a specific objection there. But can we ease
> DTS testing for firmware/bootloader projects by providing a versioned
> release package for DT bindings? Or if someone else has a better idea
> here please feel free to chime in.
This doesn't work for you?:
https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/
Note that I would like to revamp this repo to use some modern CI job,
use git_filter_repo python module rather than git-filter-branch, and
move to devicetree.org GH, but if projects aren't relying on this
repo, I'm not motivated to do that work.
Rob
On Wed, Nov 8, 2023 at 5:38 AM Ard Biesheuvel wrote:
>
> On Tue, 7 Nov 2023 at 19:07, Rob Herring wrote:
> >
> >
> > All of this:
> >
>
> > > On Mon, 16 Oct 2023 at 15:54, Simon Glass wrote:
> > > >
> > > > It is not specific to
top. There's not really wiggle room there either.
> >
> > That is really the problem, I agree.
>
> And we need to accept that, and what is/isn't something that we can
> expect every board developer to have to tweak on top of this.
>
> Heck, maybe part of the issue here is that devicetree-the-spec and
> devicetree-the-linux-kernel-input need a little differentiation and some
> official statement along the lines of "just because X can be in the
> device tree does not mean that X will be defined in the device tree, if
> it can be detected in some other reliable manner" for the latter.
I think Andre's statement is just missing 1 word: required
A devicetree is only *required* for peripherals *that cannot be
located by probing*.
But really I'd phrase it in terms of what's needed for discoverable devices.
I'm somewhat surprised at this point in time we need a statement, but
happy to add something to the DT spec. DT has been optional for
PCI/USB since the advent of FDT and only used there when there's extra
resources which are not discoverable. It only seems to be a question
when it's a not $sig bus.
> > But I would be happy with a u-boot.dtsi file to resolve this, while we
> > wait. I believe a binding makes sense in this case.
>
> We don't need a binding, we can easily check at run-time. We only barely
> have to worry about run-time failing (yes, QEMU could be fired up with a
> model that lacks it, or some future change, and it's cheap to check). I
> would say we could use the cpu compatible as a binding, but I don't want
> to then have to add a bootph property to that. And the RISC-V example
> makes it even clearer that this is not a binding thing.
>
> I do not want a binding here that we just don't upstream because it will
> make life harder for everyone else that's adding new platforms to get
> the feature to work. Or people won't get it to work and instead add new
> code that they most likely didn't need to, per drivers/timer/ today.
>
> I'll let security people argue on what level of RNG (and so perhaps RNG
> choice on systems that have more than one source available) devices need
> to be present.
There's the stance that you don't trust any of them, so use them all
and mix them together.
> But I think drivers/timer/ is the better example of
> needing to just have the source present, with minimal run-time checking
> (since it's a feature of the CPU).
Timers come up frequently (well, less so with Arm arch timer now) with
various ways to assign timers to Linux clocksource and clockevent. My
response there is what's the difference in the instances that you care
about assignment? If they are all the same, then you shouldn't. If
they aren't the same, describe the difference. Sometimes it's just one
instance has an interrupt, so it's the clockevent. Or you need the one
that's always on. The OS/client can figure that out if you describe
those properties. That's better than creating arbitrary indices.
Rob
On Tue, Oct 31, 2023 at 10:56 AM Simon Glass wrote:
>
> Hi Rob,
>
> On Mon, 16 Oct 2023 at 15:54, Simon Glass wrote:
> >
> > Hi Rob,
> >
> > On Mon, 16 Oct 2023 at 10:50, Rob Herring wrote:
> > >
> > > On Fri, Oct 13, 2023
, e.g.
> >>>> 'imx6dl-wandboard.dtb'.
> >>>> +On other architectures the file name is preceded by the vendor
> >>>> directory, e.g.
> >>>> +'rockchip/rk3326-odroid-go2.dtb'.
> >>>
> >>> The Linux Kernel has split 32bit ARM up by directory now, too.
> >>
> >> Since Linux v6.5. That is why I wrote "currently". Once we migrate the
> >> values of $fdtfile in U-Boot we may want to change
> >> distro_efi_try_bootflow_files() to search both with and without vendor
> >> directory.
> >>
> >> Are there already plans for that migration?
> >
> > Right, v6.5 is out and has this change and v6.6 will be out soon enough,
> > so the documentation we're adding here and now should be worded such
> > that doesn't get stuck on these specifics.
>
> Should I add a sentence:
>
> Linux v6.5 has added vendor directories on 32bit ARM and U-Boot is
> expected to follow suit.
Note that while this is correct, the install (make dtbs_install) still
uses a flat directory. That was to not break existing users. It is
currently not a visible config option. Perhaps it should be if there's
a desire to move to having sub-directories for the install?
Rob
On Wed, 25 Oct 2023 10:39:17 +1300, Simon Glass wrote:
> Add two compatible for binman entries, as a starting point for the
> schema.
>
> Note that, after discussion on v2, we decided to keep the existing
> meaning of label so as not to require changes to existing userspace
> software when movin
On Mon, Oct 09, 2023 at 04:04:15PM -0600, Simon Glass wrote:
> Add three properties for controlling alignment of partitions, aka
> 'entries' in binman.
>
> For now there is no explicit mention of hierarchy, so a 'section' is
> just the 'binman' node.
>
> These new properties are inputs to the pac
On Mon, Oct 09, 2023 at 04:04:14PM -0600, Simon Glass wrote:
> Add two compatible for binman entries, as a starting point for the
> schema.
>
> Note that, after discussion on v2, we decided to keep the existing
> meaning of label so as not to require changes to existing userspace
> software when m
On Mon, Oct 09, 2023 at 04:04:13PM -0600, Simon Glass wrote:
> Add a compatible string for binman, so we can extend fixed-partitions
> in various ways.
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v4:
> - Change subject line
>
> Changes in v3:
> - Drop fixed-partition additional compatib
ates typo
>
> Changes in v5:
> - Redo to make this property specific to ECC
> - Provide properties both for detection and correction
>
> Changes in v3:
> - Add new patch to update the /memory nodes
>
> dtschema/schemas/memory.yaml | 13 +
> 1 file changed, 13 insertions(+)
Applied this patch.
Rob
On Fri, Oct 13, 2023 at 4:09 PM Simon Glass wrote:
>
> Hi Rob,
>
> On Fri, 13 Oct 2023 at 13:42, Rob Herring wrote:
> >
> > On Fri, Oct 6, 2023 at 7:03 PM Simon Glass wrote:
> > >
> > > Hi Ard,
> > >
> > > On Fri, 6 Oct 2023 at 17:00,
Ard Biesheuvel wrote:
> > > >
> > > > On Mon, 2 Oct 2023 at 19:54, Simon Glass wrote:
> > > > >
> > > > > Hi Rob,
> > > > >
> > > > > On Tue, 26 Sept 2023 at 13:42, Simon Glass wrote:
> > > > >
On Mon, Oct 09, 2023 at 04:02:40PM -0600, Simon Glass wrote:
> Hi Rob,
>
> On Mon, 9 Oct 2023 at 15:18, Rob Herring wrote:
> >
> >
> > On Mon, 09 Oct 2023 14:10:00 -0600, Simon Glass wrote:
> > > Add two compatible for binman entries, as a starting point fo
d/partitions/fixed-partitions.yaml | 19 +++
> 1 file changed, 19 insertions(+)
>
Reviewed-by: Rob Herring
On Mon, 09 Oct 2023 14:10:00 -0600, Simon Glass wrote:
> Add two compatible for binman entries, as a starting point for the
> schema.
>
> Note that, after discussion on v2, we decided to keep the existing
> meaning of label so as not to require changes to existing userspace
> software when movin
getting a bit ahead of ourselves here. I thought
> > that the decision was that the label should indicate the contents.
> > If you have multiple things in a partition then it would become a
> > 'section' in Binman's terminology. Either the label programmatically
&g
On Tue, Sep 26, 2023 at 2:48 AM Miquel Raynal wrote:
>
> Hello,
>
> > > > > > These are firmware bindings, as indicated, but I
> > > > > > took them out of the /firmware node since that is for a different
> > > > > > p
or something like that.
> > And finally it looks like partition names are set depending on the
> > content that was discovered, so yes, the partition name is likely the
> > good location to tell users/OSes what's inside.
> >
> > > > > > Also, I
On Fri, 22 Sep 2023 13:34:15 -0600, Simon Glass wrote:
> Binman[1] is a tool for creating firmware images. It allows you to
> combine various binaries and place them in an output file.
>
> Binman uses a DT schema to describe an image, in enough detail that
> it can be automatically built from co
On Fri, Sep 22, 2023 at 1:12 PM Simon Glass wrote:
>
> Hi Rob,
>
> On Fri, 22 Sept 2023 at 11:46, Rob Herring wrote:
> >
> > On Fri, Sep 22, 2023 at 11:01:18AM -0600, Simon Glass wrote:
> > > Hi Rob,
> > >
> > > On Fri, 22 Sept 2023 at 10:00,
On Fri, Sep 22, 2023 at 11:01:18AM -0600, Simon Glass wrote:
> Hi Rob,
>
> On Fri, 22 Sept 2023 at 10:00, Rob Herring wrote:
> >
> > On Thu, Sep 21, 2023 at 1:45 PM Simon Glass wrote:
> > >
> > > Binman[1] is a tool for creating firmware images. It allow
re, it neither conflicts nor needs extending.
I did a bit more research. "fixed-partitions" as a compatible has
"only" been around since 2015. Prior to that, it was implicit with
just partition nodes with addresses (i.e. reg) and that dates back to
2007. Looks like u-boot only supports the newer form and since 2021.
Rob
On Thu, Sep 21, 2023 at 9:38 AM Simon Glass wrote:
>
> Hi Rob,
>
> On Thu, 21 Sept 2023 at 08:25, Rob Herring wrote:
> >
> > On Thu, Sep 7, 2023 at 4:40 PM Simon Glass wrote:
> > >
> > > It is common to split firmware into 'Platform Init'
tains code used for interacting with the system
> when
> + running; memory may be reclaimed if this code is not called
> + runtime-data: Contains data used for interacting with the system
> when
> + running; memory may be reclaimed if the runtime code is not used
"boot" vs. "runtime" seem too vague. However, if these mean EFI boot
time services and runtime services, then I understand exactly what
they are. In that case dropping 'uefi,' was a mistake. But EFI has its
own way to define these regions, right?
Rob
On Tue, Sep 19, 2023 at 3:26 PM Simon Glass wrote:
>
> Hi Rob,
>
> On Mon, 18 Sept 2023 at 11:00, Rob Herring wrote:
> >
> > On Thu, Sep 14, 2023 at 5:42 PM Simon Glass wrote:
> > >
> > > Hi Rob,
> > >
> > > On Wed, 13 Sept 2023 at 16
On Thu, Sep 14, 2023 at 5:42 PM Simon Glass wrote:
>
> Hi Rob,
>
> On Wed, 13 Sept 2023 at 16:39, Rob Herring wrote:
> >
> > On Fri, Sep 8, 2023 at 1:06 PM Mark Kettenis
> > wrote:
> > >
> > > > From: Jassi Brar
> > > >
tions...
> > > > >
> > > >
> > > > We've been this over and over again and frankly it gets a bit annoying.
> > > > It's called *DEVICE* tree for a reason. As Rob pointed out there are
> > > > exceptions, but those made a lot of
On Thu, Sep 7, 2023 at 4:40 PM Simon Glass wrote:
>
> Some memories provide ECC detection and/or correction. For software which
> wants to check memory, it is helpful to see which regions provide this
> feature.
>
> Add this as a property of the /memory nodes, since it presumably follows
> the har
multi-bit - Corrects multiple-bit ECC errors
> +
> + If not present, this is equivalent to 'none'.
One issue is with 2 properties nonsensical combinations are allowed.
Not really any way to handle that in the schema though.
Rob
++
> 1 file changed, 181 insertions(+)
> create mode 100644 dtschema/schemas/reserved-memory/reserved-memory.yaml
I've applied this one and patch 2.
Rob
Ard Biesheuvel wrote:
> > >>
> > >> On Wed, 6 Sept 2023 at 16:54, Simon Glass wrote:
> > >> >
> > >> > Hi Rob, Ard,
> > >> >
> > >> > On Wed, 6 Sept 2023 at 08:34, Rob Herring wrote:
> > &
t;->non-secure
> communication or a page with spin tables used by PSCI. None of the
> proposed labels are appropriate for this, and I'd much rather have a
> compatible string or some other property that clarifies the nature in
> a more suitable way. Note that 'no-map' already exists to indicate
> that the CPU should not map this memory unless it does so for the
> specific purpose that the reservation was made for.
I agree. I think compatible is the better approach. Some property like
'discard' may not be sufficient information if the OS needs to consume
the region first and then discard it. Better to state exactly what's
there and then the OS can imply the rest.
Rob
they don't describe
> > anything to do with hardware, or generally even the runtime of a
> > device, they don't even describe the boot/runtime state of the
> > firmware, they describe build time, so I don't see what that has to do
> > with device tree? Can you explain that? To me those sorts of things
> > should live in a build time style config file.
For the record, I tend to agree.
> I beg to differ. Devicetree is more than just hardware and always has
> been. See, for example the /chosen and /options nodes.
There are exceptions...
> We need run-time configuration here, since we cannot know at build
> time what we will be asked to do by a previous firmware phase.
Really, I don't want to have to care about the binman binding. If it is
u-boot specific, then it should stay in u-boot. I took /options/u-boot/,
but now I'm starting to have second thoughts on that being in dtschema
if it is going to be continually and frequently extended. Validating it
in SR does little. If a vendor is abusing /options/u-boot/ in some way
they could just as easily remove the node in their u-boot fork to pass.
SR is certainly not going to require the node be there.
On A/B updates, that really doesn't seem like a u-boot specific problem
to me. No one wants A/B updates in EDK2 or anything else?
Rob
it-ecc";
Or maybe that's valid? If so, how would we express that?
Why do we need "no-ecc"? Is that the same as no "attr" property?
I think it's better if we have 'ecc-type' or something? Or generally,
a property per class/type of attribute.
Rob
rved-memory/phram.yaml
Depends on mtd.yaml in the kernel, so no.
> create mode 100644 dtschema/schemas/reserved-memory/qcom,cmd-db.yaml
> create mode 100644 dtschema/schemas/reserved-memory/qcom,rmtfs-mem.yaml
No.
> create mode 100644 dtschema/schemas/reserved-memory/ramoops.yaml
Probably not.
> create mode 100644 dtschema/schemas/reserved-memory/shared-dma-pool.yaml
Maybe.
Rob
On Tue, Aug 22, 2023 at 3:34 PM Simon Glass wrote:
>
> Hi Rob,
>
> On Tue, 22 Aug 2023 at 12:53, Rob Herring wrote:
> >
> > On Mon, Aug 21, 2023 at 2:48 PM Simon Glass wrote:
> > >
> > > The Devicespec specification skips over handling of a logical vi
On Mon, Aug 21, 2023 at 2:48 PM Simon Glass wrote:
>
> The Devicespec specification skips over handling of a logical view of
> the memory map, pointing users to the UEFI specification.
It's more that the DT spec defines what is not used with UEFI. If UEFI
covers more than the DT Spec defined, the
s. SCMI for
example. PSCI is another example, but it predated using /firmware so
it's typically just put at the top level (and also PSCI should have
been made discoverable like any SMCCC interface).
> +
> + [1] https://github.com/fwupd/fwupd/tree/main/plugins/vbe
> +
> +properties:
> + $nodename:
> +const: firmware
> +
> + "#address-cells": true
> + "#size-cells": true
What address space is this? It's not memory mapped because you don't
have 'ranges'.
Rob
p by a description of their meanings.
>
> fin
> ===
>
> Create a new file to store the extension meanings and a new
> riscv,isa-base property to replace the aspect of riscv,isa that is
> not represented by the new property - the base ISA implemented by a hart.
&
On Mon, Jun 12, 2023 at 3:23 PM Conor Dooley wrote:
>
> Rob,
> Before I press on with more versions...
>
> On Thu, Jun 08, 2023 at 08:30:28PM +0100, Conor Dooley wrote:
> > On Thu, Jun 08, 2023 at 01:15:37PM -0600, Rob Herring wrote:
> > > On Tue, May 30, 2023 at
On Thu, Jun 8, 2023 at 12:05 PM Conor Dooley wrote:
>
> On Thu, Jun 08, 2023 at 11:49:08AM -0600, Rob Herring wrote:
> > On Thu, 08 Jun 2023 17:54:05 +0100, Conor Dooley wrote:
>
> > > As a result of implementing Sean's suggestion, I believe I need to add
>
rties: false.
That's an issue on my radar to fix. I started that for the Arm cpus.yaml
a while back. Sadly it involves adding all the misc properties vendors
added. It's not a lot, but still better to get in front of that for
Risc-V.
> > Rob's AFK at the moment, and I was h
lemented by a hart.
> Originally I proposed properties in the cpu node, rather than as a child
> of the cpu node, but some concerns were raised about the size of the dtb
> for systems with dozens of cpus & dozens of extensions. Using a child
> node, and dropping the "riscv,isa-ex
gt; On Thu, May 04, 2023 at 10:39:06AM -0500, Jassi Brar wrote:
> > > > On Thu, 4 May 2023 at 10:19, Rob Herring wrote:
> > > > > On Thu, May 4, 2023 at 9:01 AM Jassi Brar
> > > > > wrote:
> > > > >
> > > > > > I may be wron
ms which would have MTD based partitioning schemes. Same for all
> > > GPT partitioned devices. Again, as for the need for a separate node
> > > with the compatible property, it is as per the driver model design.
> > > For the other properties, we can indeed have them
> > > bindings.
> > >
> > > There exists no code yet, so we can change the fwu-mtd bindings
> > > to contain all properties within the fwu-mdata node.
> > >
> > > Signed-off-by: Jassi Brar
> > > ---
> > >
> > > Hi Rob,
+boot-architecture
On Mon, Feb 6, 2023 at 3:25 PM Simon Glass wrote:
>
> Hi Rob,
>
> On Mon, 6 Feb 2023 at 10:15, Rob Herring wrote:
> >
> > On Sat, Feb 4, 2023 at 6:04 AM Simon Glass wrote:
> > >
> > > Hi Peter,
> > >
>
>
> Possibly...can you please be a little more specific?
Peter is talking about the same thing I suggested on IRC.
pstore == ramoops
Rob
On Tue, Jan 24, 2023 at 9:56 AM Abdellatif El Khlifi
wrote:
>
> On Mon, Jan 23, 2023 at 09:32:28AM -0700, Simon Glass wrote:
> > Hi Rob,
> >
> > On Mon, 23 Jan 2023 at 08:13, Rob Herring wrote:
> > >
> > > On Fri, Jan 20, 2023 at 4:04 PM
On Fri, Jan 20, 2023 at 4:04 PM Simon Glass wrote:
>
> Hi Rob,
>
> On Thu, 19 Jan 2023 at 11:11, Rob Herring wrote:
> >
> > On Thu, Jan 19, 2023 at 10:41 AM Simon Glass wrote:
> > >
> > > Hi Abdellatif,
> > >
> > > On
have to let everyone invent a new discovery
> > > > > method every time?
> > > >
> > > >
> > > > No one needs to invent any discovery method every time if the firmware
> > > > specification
> > > > provides one and as R
3:44, Abdellatif El Khlifi
> > > wrote:
> > > >
> > > > On Thu, Jan 12, 2023 at 04:43:32PM -0700, Simon Glass wrote:
> > > > > Hi Rob,
> > > > >
> > > > > On Wed, 11 Jan 2023 at 19:10, Rob Herring wrote:
> > >
On Thu, Jan 12, 2023 at 5:43 PM Simon Glass wrote:
>
> Hi Rob,
>
> On Wed, 11 Jan 2023 at 19:10, Rob Herring wrote:
> >
> > On Mon, Dec 19, 2022 at 1:21 PM Simon Glass wrote:
> > >
> > > Hi Abdellatif,
> > >
> > > On
7;s done by adding proper values. Actual offsets
> are picked by manufacturers and vary across devices.
>
> Signed-off-by: Rafał Miłecki
> ---
> .../devicetree/bindings/nvmem/layouts/u-boot,env.yaml | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
Reviewed-by: Rob Herring
me Documentation/devicetree/bindings/nvmem/{ => layouts}/u-boot,env.yaml
> (77%)
>
Reviewed-by: Rob Herring
On Mon, Dec 19, 2022 at 1:21 PM Simon Glass wrote:
>
> Hi Abdellatif,
>
> On Mon, 19 Dec 2022 at 04:12, Abdellatif El Khlifi
> wrote:
> >
> > On Mon, Dec 05, 2022 at 09:49:30AM -0600, Rob Herring wrote:
> > > On Sun, Dec 4, 2022 at 1:22 PM Simon
On Thu, Nov 10, 2022 at 10:59 AM Simon Glass wrote:
>
> U-Boot has some particular challenges with device tree and devices:
>
> - U-Boot has multiple build phases, such as a Secondary Program Loader
> (SPL) phase which typically runs in a pre-SDRAM environment where code
> and data space are l
that is probably due to the addition
of the timer class 2 years later, not that the commit was wrong/broken
at the time.
Rob
On Thu, Jan 05, 2023 at 06:10:36PM +0100, Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> U-Boot's "ethaddr" environment variable is very often used to store
> *base* MAC address. It's used as a base for calculating addresses for
> multiple interfaces. It's done by adding proper values. Actual off
On Sat, Dec 24, 2022 at 6:04 AM Paul Barker wrote:
>
> On 20/12/2022 15:55, Rob Herring wrote:
> > On Wed, Nov 23, 2022 at 05:50:06PM +, Paul Barker wrote:
> >> Add properties to the Authenta SPI flash device node to enable access by
> >> a UEFI
ith its little endian order. A GUID as a string is readily
identifiable as a GUID.
Why is this u-boot specific? Another UEFI implementation doesn't need
the GUID?
Rob
Hi Jack,
Thanks for your suggestion, I hadn't thought of using just the rkbin ddr file
together with u-boot SPL. My biggest objection was the rkbin miniloader that
makes assumptions on partition layout.
It seems to work, but now I'm in for some DT pain :)
Cheers,
Rob
9 Dec 202
'active_clk_edges' and 'chipselect_num' SPI controller properties are
unused in u-boot and Linux. They are also not documented in the binding.
So drop them.
Signed-off-by: Rob Herring
---
arch/arm/dts/synquacer-sc2a11-developerbox-u-boot.dtsi | 2 --
1 file changed, 2 deleti
The 'base' GPIO controller property is unused in u-boot and Linux. It is
also not documented in the binding. So drop it.
Signed-off-by: Rob Herring
---
arch/arm/dts/synquacer-sc2a11.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/dts/synquacer-sc2a11.dtsi
b/ar
the heatsink is blocking sight and seems to be
attached with some sort of thermal glue.
Is there a way to read back the DDR timings (phy-timing, sdram-params)
from the kernel/SoC on a board that is booted using the proprietary loader?
Cheers!
Rob
The "arm,armv7-timer-mem" schema defines the address sizes for child
nodes to be 32-bit as there's no need for 64-bit offsets and sizes of
the child 'frame' nodes.
Signed-off-by: Rob Herring
---
arch/arm/dts/synquacer-sc2a11.dtsi | 10 +-
1 file changed, 5 i
The correct value for 'entry-method' in the idle-states binding is 'psci',
not 'arm,psci'. It hasn't mattered because it isn't used by the OS.
Signed-off-by: Rob Herring
---
arch/arm/dts/synquacer-sc2a11.dtsi | 2 +-
1 file changed, 1 insertion(+),
'arm,armv8' compatible is for software models only. so drop it from cpu
nodes.
Signed-off-by: Rob Herring
---
arch/arm/dts/synquacer-sc2a11.dtsi | 48 +++---
1 file changed, 24 insertions(+), 24 deletions(-)
diff --git a/arch/arm/dts/synquacer-sc2a
DT node names should follow generic names defined in the DT spec. These
are also now checked by dtschema tools.
Signed-off-by: Rob Herring
---
arch/arm/dts/synquacer-sc2a11-developerbox-u-boot.dtsi | 2 +-
arch/arm/dts/synquacer-sc2a11-developerbox.dts | 2 +-
arch/arm/dts/synquacer
This is a series of DT fixes for the Synquacer. These issues were found
running the dtschema tools.
I don't have a board, but Ilias has tested the changes for me. Thanks!
Signed-off-by: Rob Herring
---
Rob Herring (4):
dts: synquacer: Drop CPU 'arm,armv8' compat
On Sun, Dec 4, 2022 at 1:22 PM Simon Glass wrote:
>
> Hi Rob,
>
> On Tue, 29 Nov 2022 at 05:22, Rob Herring wrote:
> >
> > On Fri, Nov 25, 2022 at 3:18 PM Simon Glass wrote:
> > >
> > > Hi Abdellatif,
> > >
> > > On T
> +{
> > > > + int ret;
> > > > + struct udevice *dev = NULL;
> > > > +
> > > > + ret = device_bind(dm_root(), DM_DRIVER_GET(arm_ffa),
> > > > FFA_DRV_NAME, NULL, ofnode_null(),
> > > > +
+Ilias, Bill and Joakim
On Sat, Nov 12, 2022 at 9:21 AM Simon Glass wrote:
>
> Hi Rob,
>
> (unfortunately I have a filter on this list due to the insane traffic
> and am not sure how to let these emails through, so I just saw this)
https://lore.kernel.org/linux-device
On Thu, Nov 10, 2022 at 10:59 AM Simon Glass wrote:
>
> Hi Rob,
>
> On Tue, 8 Nov 2022 at 10:19, Rob Herring wrote:
> >
> > On Tue, Nov 1, 2022 at 10:13 PM Simon Glass wrote:
> > >
> > > U-Boot has some particular challenges with device tree and device
On Tue, Nov 1, 2022 at 10:13 PM Simon Glass wrote:
>
> U-Boot has some particular challenges with device tree and devices:
>
> - U-Boot has multiple build phases, such as a Secondary Program Loader
> (SPL) phase which typically runs in a pre-SDRAM environment where code
> and data space are li
On Tue, 18 Oct 2022 17:42:02 +0200, Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> Broadcom uses U-Boot for a lot of their bcmbca familiy chipsets. U-Boot
> stores its configuration in an environment data block.
>
> Such blocks are usually stored on flash as a separated partition at
> hardcode
On Tue, 18 Oct 2022 17:42:01 +0200, Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> U-Boot partition may contain subpartitions. For example Broadcom
> includes environment data block in the middle of its U-Boot partition.
>
> This allows describing Broadcom's U-Boot env data and will allow
> re
On Tue, Oct 18, 2022 at 9:10 AM Conor Dooley wrote:
>
> On Tue, Oct 18, 2022 at 03:58:38PM +0200, Rafał Miłecki wrote:
> > On 18.10.2022 12:19, Conor Dooley wrote:
> > > On Fri, Oct 14, 2022 at 04:09:40PM -0500, Rob Herring wrote:
> > > > On Fri, 30 Sep 2022 18
On Tue, Oct 18, 2022 at 5:19 AM Conor Dooley wrote:
>
> On Fri, Oct 14, 2022 at 04:09:40PM -0500, Rob Herring wrote:
> > On Fri, 30 Sep 2022 18:36:31 +0200, Rafał Miłecki wrote:
> > > From: Rafał Miłecki
> > >
> > > Broadcom uses U-Boot for a lot o
1 - 100 of 1014 matches
Mail list logo
