schemas/interrupt-controller/riscv,imsics.yaml#
> /home/danielhb/work/qemu/riscv64_virt.dtb: imsics@2800: Unevaluated
> properties are not allowed ('compatible' was unexpected)
> from schema $id:
> http://devicetree.org/schemas/interrupt-controller/riscv,imsics.yaml#
I'm not
On Thu, May 30, 2024 at 09:26:58AM -0300, Daniel Henrique Barboza wrote:
>
>
> On 5/30/24 08:06, Andrew Jones wrote:
> > On Thu, May 30, 2024 at 01:05:41PM GMT, Andrew Jones wrote:
> > > On Thu, May 30, 2024 at 05:49:49AM GMT, Daniel Henrique Barboza wrote:
> > > > We need #address-cells
Christoph linked here on his submission to Linux of a fix for this, so I
am reviving this to leave a couple comments :)
On Thu, Feb 15, 2024 at 02:24:02PM +1000, Alistair Francis wrote:
> On Mon, Feb 5, 2024 at 6:37 PM Christoph Müllner
> wrote:
> > On Mon, Feb 5, 2024 at 3:42 AM Alistair
On Mon, Mar 04, 2024 at 06:25:39PM +0800, Fei Wu wrote:
> +name = riscv_isa_string(cpu_ptr);
> +qemu_fdt_setprop_string(ms->fdt, cpu_name, "riscv,isa", name);
> +g_free(name);
Please use riscv_isa_write_fdt() here so that you populate more than the
deprecated property
> > No they can't. For a "regular extension" you populate the DT with the
> > extension. For these extensions it has to put negated properties in the
> > DT, otherwise it is incorrectly describing the hardware it is emulating.
> > That is handling them differently in my book! If QEMU generates an
On Thu, Feb 15, 2024 at 08:11:45PM +0100, Andrew Jones wrote:
> On Thu, Feb 15, 2024 at 04:34:32PM +0000, Conor Dooley wrote:
> > On Thu, Feb 15, 2024 at 03:26:18PM +0100, Andrew Jones wrote:
> > > On Thu, Feb 15, 2024 at 01:33:47PM +, Conor Dooley wrote:
> > > >
On Thu, Feb 15, 2024 at 03:26:18PM +0100, Andrew Jones wrote:
> On Thu, Feb 15, 2024 at 01:33:47PM +0000, Conor Dooley wrote:
> > On Fri, Feb 02, 2024 at 12:21:51PM -0300, Daniel Henrique Barboza wrote:
> > > The RVA22U64 and RVA22S64 profiles mandates certain extensions that,
&
On Fri, Feb 02, 2024 at 12:21:51PM -0300, Daniel Henrique Barboza wrote:
> The RVA22U64 and RVA22S64 profiles mandates certain extensions that,
> until now, we were implying that they were available.
>
> We can't do this anymore since named features also has a riscv,isa
> entry. Let's add them to
On Tue, Jan 30, 2024 at 12:43:25PM +0100, Christoph Müllner wrote:
> On Tue, Jan 30, 2024 at 12:12 PM LIU Zhiwei
> wrote:
> >
> > thead-c906 uses some flags in pte [60-63] bits. It has history reasons that
> > SVPBMT didn't exist when thead-c906 came to world.
> >
> > We named this feature as
On Wed, Jan 24, 2024 at 02:27:10PM +0100, Björn Töpel wrote:
> Conor Dooley writes:
>
> > On Wed, Jan 24, 2024 at 01:49:51PM +0100, Björn Töpel wrote:
> >> Hi!
> >>
> >> I bumped the RISC-V Linux kernel CI to use qemu 8.2.0, and realized that
> &g
On Wed, Jan 24, 2024 at 01:49:51PM +0100, Björn Töpel wrote:
> Hi!
>
> I bumped the RISC-V Linux kernel CI to use qemu 8.2.0, and realized that
> thead c906 didn't boot anymore. Bisection points to commit d6a427e2c0b2
> ("target/riscv/cpu.c: restrict 'marchid' value")
>
> Reverting that commit,
From: Conor Dooley
A few months ago I submitted a patch to various lists, deprecating
"riscv,isa" with a lengthy commit message [0] that is now commit
aeb71e42caae ("dt-bindings: riscv: deprecate riscv,isa") in the Linux
kernel tree. Primarily, the goal was to replace "
From: Conor Dooley
Making it a series to keep the standalone change to riscv_isa_string()
that Drew reported separate.
Changes in v4:
- Other than a rebase, add a helper for the mxl_max to xlen conversion
Changes in v3:
- g_free() isa_extensions too
- use misa_mxl_max rather than the compile
From: Conor Dooley
A cpu may not have the same xlen as the compile time target, and
misa_mxl_max is the source of truth for what the hart supports.
The conversion from misa_mxl_max to xlen already has one user, so
introduce a helper and use that to populate the isa string.
Link: https
On Mon, Jan 22, 2024 at 03:24:19PM +1000, Alistair Francis wrote:
> On Wed, Jan 10, 2024 at 8:27 PM Conor Dooley wrote:
> >
> > From: Conor Dooley
> >
> > Making it a series to keep the standalone change to riscv_isa_string()
> > that Drew reported separate.
&g
From: Conor Dooley
A cpu may not have the same xlen as the compile time target, and
misa_mxl_max is the source of truth for what the hart supports.
Reported-by: Andrew Jones
Link: https://lore.kernel.org/qemu-riscv/20240108-efa3f83dcd3997dc0af458d7@orel/
Signed-off-by: Conor Dooley
From: Conor Dooley
Making it a series to keep the standalone change to riscv_isa_string()
that Drew reported separate.
Changes in v3:
- g_free() isa_extensions too
- use misa_mxl_max rather than the compile target for the base isa
- add a new patch changing riscv_isa_string() to do the same
From: Conor Dooley
A few months ago I submitted a patch to various lists, deprecating
"riscv,isa" with a lengthy commit message [0] that is now commit
aeb71e42caae ("dt-bindings: riscv: deprecate riscv,isa") in the Linux
kernel tree. Primarily, the goal was to replace "
From: Conor Dooley
A few months ago I submitted a patch to various lists, deprecating
"riscv,isa" with a lengthy commit message [0] that is now commit
aeb71e42caae ("dt-bindings: riscv: deprecate riscv,isa") in the Linux
kernel tree. Primarily, the goal was to replace "
On Wed, Nov 29, 2023 at 11:37:00AM -0300, Daniel Henrique Barboza wrote:
> On 11/29/23 07:39, Conor Dooley wrote:
> > From: Conor Dooley
> >
> > A few months ago I submitted a patch to various lists, deprecating
> > "riscv,isa" with a lengthy
From: Conor Dooley
A few months ago I submitted a patch to various lists, deprecating
"riscv,isa" with a lengthy commit message [0] that is now commit
aeb71e42caae ("dt-bindings: riscv: deprecate riscv,isa") in the Linux
kernel tree. Primarily, the goal was to replace "
On Thu, Jul 27, 2023 at 11:12:34AM -0300, Daniel Henrique Barboza wrote:
>
>
> On 7/27/23 10:59, Conor Dooley wrote:
> > Hey Daniel,
> >
> > On Thu, Jul 20, 2023 at 02:19:31PM -0300, Daniel Henrique Barboza wrote:
> > > The 'max' CPU type is used by
From: Conor Dooley
On a dtb dumped from the virt machine, dt-validate complains:
soc: pmu: {'riscv,event-to-mhpmcounters': [[1, 1, 524281], [2, 2, 524284],
[65561, 65561, 524280], [65563, 65563, 524280], [65569, 65569, 524280]],
'compatible': ['riscv,pmu']} should not be valid under {'type
Hey Daniel,
On Thu, Jul 20, 2023 at 02:19:31PM -0300, Daniel Henrique Barboza wrote:
> The 'max' CPU type is used by tooling to determine what's the most
> capable CPU a current QEMU version implements. Other archs such as ARM
> implements this type. Let's add it to RISC-V.
>
> What we consider
GPIO support
> > c6a3573 lib: utils: Fix sbi_hartid_to_scratch() usage in ACLINT drivers
> > 057eb10 lib: utils/gpio: Fix RV32 compile error for designware GPIO driver
> >
> > Signed-off-by: Bin Meng
>
> Reviewed-by: Alistair Francis
>
> @Conor Dooley @Conor Doo
On Wed, Jul 19, 2023 at 11:32:55AM +1000, Alistair Francis wrote:
> If there is no OpenSBI 1.3.1 release we should add something to the
> release notes. @Conor Dooley are you able to give a clear sentence on
> how the boot fails?
Uhh, I'll give it a shot, but hopefully it is not
On Mon, Jul 17, 2023 at 08:11:09PM -0300, Daniel Henrique Barboza wrote:
> On 7/17/23 19:33, Conor Dooley wrote:
> > On Mon, Jul 17, 2023 at 06:54:17PM -0300, Daniel Henrique Barboza wrote:
> > > Hi,
> > >
> > > I decided to include flags for both timer/counte
Hey,
On Mon, Jul 17, 2023 at 06:54:17PM -0300, Daniel Henrique Barboza wrote:
> Hi,
>
> I decided to include flags for both timer/counter extensions to make it
> easier for us later on when dealing with the RVA22 profile (which
> includes both).
>
> The features were already implemented by
ec of the extensions we're enabling. There's no
> need for more 8.1 band-aids.
>
> Cc: Conor Dooley
Does the job, thanks for doing this.
Tested-by: Conor Dooley
Cheers,
Conor.
signature.asc
Description: PGP signature
On Fri, Jul 14, 2023 at 11:19:34AM +0100, Conor Dooley wrote:
> On Fri, Jul 14, 2023 at 10:00:19AM +0530, Anup Patel wrote:
>
> > >
On Fri, Jul 14, 2023 at 10:00:19AM +0530, Anup Patel wrote:
> > > OpenSBI v1.3
> > >_ _
> > > / __ \ / | _ \_ _|
> > > | | | |_ __ ___ _ __ | (___ | |_) || |
> > > | | | | '_ \ / _ \ '_ \ \___ \| _ < | |
> > > | |__| | |_)
On Thu, Jul 13, 2023 at 11:12:33PM +0100, Conor Dooley wrote:
> +CC OpenSBI Mailing list
>
> I've not yet had the chance to bisect this, so adding the OpenSBI folks
> to CC in case they might have an idea for what to try.
NVM this, I bisected it. Logs below.
> And a questio
On Thu, Jul 13, 2023 at 07:35:01PM -0300, Daniel Henrique Barboza wrote:
> On 7/13/23 19:12, Conor Dooley wrote:
> > And a question for you below Daniel.
> >
> > On Wed, Jul 12, 2023 at 11:14:21PM +0100, Conor Dooley wrote:
> >
> > > qemu-system-riscv
+CC OpenSBI Mailing list
I've not yet had the chance to bisect this, so adding the OpenSBI folks
to CC in case they might have an idea for what to try.
And a question for you below Daniel.
On Wed, Jul 12, 2023 at 11:14:21PM +0100, Conor Dooley wrote:
> On Wed, Jul 12, 2023 at 06:39:28PM -0
On Wed, Jul 12, 2023 at 06:39:28PM -0300, Daniel Henrique Barboza wrote:
> On 7/12/23 18:35, Conor Dooley wrote:
> > On Wed, Jul 12, 2023 at 06:09:10PM -0300, Daniel Henrique Barboza wrote:
> >
> > > It is intentional. Those default marchid/mimpid vals were derived
On Wed, Jul 12, 2023 at 06:09:10PM -0300, Daniel Henrique Barboza wrote:
> It is intentional. Those default marchid/mimpid vals were derived from the
> current
> QEMU version ID/build and didn't mean much.
>
> It is still possible to set them via "-cpu rv64,marchid=N,mimpid=N" if needed
> when
On Wed, Jul 12, 2023 at 05:30:41PM -0300, Daniel Henrique Barboza wrote:
> On 7/12/23 16:22, Conor Dooley wrote:
> > On Wed, Jul 12, 2023 at 04:01:48PM -0300, Daniel Henrique Barboza wrote:
> > > The 'max' CPU type is used by tooling to determine what's the most
> > >
On Wed, Jul 12, 2023 at 04:01:48PM -0300, Daniel Henrique Barboza wrote:
> The 'max' CPU type is used by tooling to determine what's the most
> capable CPU a current QEMU version implements. Other archs such as ARM
> implements this type. Let's add it to RISC-V.
>
> What we consider "most capable
On Wed, Jul 05, 2023 at 07:00:52PM -0300, Daniel Henrique Barboza wrote:
>
>
> On 7/5/23 18:49, Conor Dooley wrote:
> > On Wed, Jul 05, 2023 at 06:39:37PM -0300, Daniel Henrique Barboza wrote:
> > > The absence of a satp mode in riscv_host_cpu_init() is causing t
On Wed, Jul 05, 2023 at 06:39:37PM -0300, Daniel Henrique Barboza wrote:
> The absence of a satp mode in riscv_host_cpu_init() is causing the
> following error:
>
> $ ./qemu/build/qemu-system-riscv64 -machine virt,accel=kvm \
> -m 2G -smp 1 -nographic -snapshot \
> -kernel
On Thu, Apr 27, 2023 at 01:28:18PM +0800, Yu-Chien Peter Lin wrote:
> Hi Conor,
>
> Thank you for your prompt response.
>
> On Fri, Apr 21, 2023 at 06:59:40PM +0100, Conor Dooley wrote:
> > On Fri, Apr 21, 2023 at 09:14:37PM +0800, Yu Chien Peter Lin wrote:
> > > T
On Fri, Apr 21, 2023 at 09:14:37PM +0800, Yu Chien Peter Lin wrote:
> The length of fdt_event_ctr_map[20] will add 5 dummy cells in
> "riscv,event-to-mhpmcounters" property, so directly initialize
> the array without an explicit size.
>
> This patch also fixes the typo of PMU cache operation
From: Conor Dooley
dt-validate complains:
> soc: pmu: {'riscv,event-to-mhpmcounters':
> [[1, 1, 524281], [2, 2, 524284], [65561, 65561, 524280],
> [65563, 65563, 524280], [65569, 65569, 524280], [0, 0, 0], [0, 0]],
> pmu: riscv,event-to-mhpmcounters:6: [0, 0] is too short
There
On Thu, Feb 02, 2023 at 03:37:17PM -0300, Daniel Henrique Barboza wrote:
> On 2/2/23 14:25, Conor Dooley wrote:
> > On Thu, Feb 02, 2023 at 10:58:07AM -0300, Daniel Henrique Barboza wrote:
> > > This new version removed the translate_fn() from patch 1 because it
> > &g
U
> - v9 link: https://lists.gnu.org/archive/html/qemu-devel/2023-01/msg04509.html
I think my T-b got lost last time around, but I gave this version a
whirl too & things are working for me as they were before on Icicle.
For the series:
Tested-by: Conor Dooley
Thanks,
Conor.
>
>
" case that fail before, is now back passing again. Thanks
Daniel!
Tested-by: Conor Dooley
signature.asc
Description: PGP signature
should re-send v2, this time explaining why the
> existing function
> will not break the Microchip board because we'll never put the FDT out of the
> LO area
> of the board. Does this work for you?
> Conor, one more thing:
>
>
> On 1/19/23 21:15, Conor Dooley wrote:
Hey Daniel,
Got through the stuff I wanted to get done tonight faster than
expected...
On Thu, Jan 19, 2023 at 05:17:33PM -0300, Daniel Henrique Barboza wrote:
> Are you testing it by using the command line
> you mentioned in the "qemu icicle kit es" thread?
>
> $(QEMU)/qemu-system-riscv64 \
>
Hey!
On Thu, Jan 19, 2023 at 04:17:24PM -0300, Daniel Henrique Barboza wrote:
> The Icicle Kit board works with 2 distinct RAM banks that are separated
> by a gap. We have a lower bank with 1GiB size, a gap follows,
> then at 64GiB the high memory starts.
>
> MachineClass::default_ram_size is
eferenceManuals/PolarFire_SoC_FPGA_MSS_Technical_Reference_Manual_VC.pdf
Reviewed-by: Conor Dooley
Thanks!
>
> Fixes: 56f6e31e7b7e ("hw/riscv: Initial support for Microchip PolarFire SoC
> Icicle Kit board")
> Signed-off-by: Bin Meng
> ---
>
> include/hw/riscv
On Wed, Aug 24, 2022 at 03:17:00PM -0700, Atish Patra wrote:
> Qemu virt machine can support few cache events and cycle/instret counters.
> It also supports counter overflow for these events.
>
> Add a DT node so that OpenSBI/Linux kernel is aware of the virt machine
> capabilities. There are
From: Conor Dooley
The system controller on PolarFire SoC is access via a mailbox. The
control registers for this mailbox lie in the "IOSCB" region & the
interrupt is cleared via write to the "SYSREG" region. It also has a
QSPI controller, usually connected to a
From: Conor Dooley
The Fabric Interconnect Controllers provide interfaces between the FPGA
fabric and the core complex. There are 5 FICs on PolarFire SoC, numbered
0 through 4. FIC2 is an AXI4 slave interface from the FPGA fabric and
does not show up on the MSS memory map. FIC4 is dedicated
From: Conor Dooley
Hey all,
Apart from DDR (see [1]), these should be the last bits needed to get
recent Linux kernels booting again for Icicle/PolarFire SoC. Previously,
I had been disabling the hwrng and PCI but I keep forgetting that is
required and decided to fix that.
I'm not entirely sure
From: Conor Dooley
On PolarFire SoC, some peripherals (eg the PCI root port) are clocked by
"Clock Conditioning Circuitry" in the FPGA. The specific clock depends
on the FPGA bitstream & can be locked to one particular {D,P}LL - in the
Icicle Kit Reference Design v20
On Sat, Nov 12, 2022 at 01:34:15PM +, Conor Dooley wrote:
> From: Conor Dooley
>
> The system controller on PolarFire SoC is access via a mailbox. The
> control registers for this mailbox lie in the "IOSCB" region & the
> interrupt is cleared via write to the
On Sun, Nov 13, 2022 at 08:30:42PM +0100, Philippe Mathieu-Daudé wrote:
> Hi Conor,
>
> On 12/11/22 14:34, Conor Dooley wrote:
> > From: Conor Dooley
> >
> > The system controller on PolarFire SoC is access via a mailbox. The
> > control registers for this
From: Conor Dooley
Hey all,
But of a v2 of what I sent the other day [0]..
Apart from DDR (see [1]), these should be the last bits needed to get
recent Linux kernels booting again for Icicle/PolarFire SoC. Previously,
I had been disabling the hwrng and PCI but I keep forgetting that is
required
From: Conor Dooley
The system controller on PolarFire SoC is access via a mailbox. The
control registers for this mailbox lie in the "IOSCB" region & the
interrupt is cleared via write to the "SYSREG" region. It also has a
QSPI controller, usually connected to a
From: Conor Dooley
The Fabric Interconnect Controllers provide interfaces between the FPGA
fabric and the core complex. There are 5 FICs on PolarFire SoC, numbered
0 through 4. FIC2 is an AXI4 slave interface from the FPGA fabric and
does not show up on the MSS memory map. FIC4 is dedicated
From: Conor Dooley
On PolarFire SoC, some peripherals (eg the PCI root port) are clocked by
"Clock Conditioning Circuitry" in the FPGA. The specific clock depends
on the FPGA bitstream & can be locked to one particular {D,P}LL - in the
Icicle Kit Reference Design v20
On Sat, Nov 12, 2022 at 08:37:38AM +0800, Bin Meng wrote:
> Hi Conor,
>
> On Sat, Nov 12, 2022 at 8:31 AM Conor Dooley wrote:
> >
> > On Thu, Nov 10, 2022 at 12:18:44AM +0100, Philippe Mathieu-Daudé wrote:
> > > Hi Conor,
> > >
> > > On 9/11/2
On Thu, Nov 10, 2022 at 12:18:44AM +0100, Philippe Mathieu-Daudé wrote:
> Hi Conor,
>
> On 9/11/22 20:08, Conor Dooley wrote:
> > From: Conor Dooley
> >
> > @@ -168,6 +170,10 @@ static void mchp_pfsoc_ioscb_realize(DeviceSt
On Thu, Nov 10, 2022 at 12:18:44AM +0100, Philippe Mathieu-Daudé wrote:
> On 9/11/22 20:08, Conor Dooley wrote:
> > From: Conor Dooley
> >
> > On PolarFire SoC, some peripherals (eg the PCI root port) are clocked by
> > "Clock Conditioning Circuitry" in
From: Conor Dooley
On PolarFire SoC, some peripherals (eg the PCI root port) are clocked by
"Clock Conditioning Circuitry" in the FPGA. The specific clock depends
on the FPGA bitstream & can be locked to one particular {D,P}LL - in the
Icicle Kit Reference Design v20
From: Conor Dooley
Booting using "Direct Kernel Boot" for PolarFire SoC & skipping u-boot
entirely is probably not advisable, but it does at least show signs of
life. Recent Linux kernel versions make use of peripherals that are
missing definitions in QEMU and lead to kernel panics
From: Conor Dooley
"uart" is not a node name that complies with the dt-schema.
Change the node name to "serial" to ix warnings seen during
dt-validate on a dtbdump of the virt machine such as:
/stuff/qemu/qemu.dtb: uart@1000: $nodename:0: 'uart@1000' does
From: Conor Dooley
The device trees produced automatically for the virt and spike machines
fail dt-validate on several grounds. Some of these need to be fixed in
the linux kernel's dt-bindings, but others are caused by bugs in QEMU.
I mostly opted for what appeared to be the smallest change
From: Conor Dooley
The reset and poweroff features of the syscon were originally added to
top level, which is a valid path for a syscon subnode. Subsequently a
reorganisation was carried out while implementing NUMA in which the
subnodes were moved into the /soc node. As /soc is a "simpl
From: Conor Dooley
When optional AIA PLIC support was added the to the virt machine, the
address cells property was removed leading the issues with dt-validate
on a dump from the virt machine:
/stuff/qemu/qemu.dtb: plic@c00: '#address-cells' is a required property
From schema
From: Conor Dooley
"platform" is not a valid name for a bus node in dt-schema, so warnings
can be see in dt-validate on a dump of the riscv virt dtb:
/stuff/qemu/qemu.dtb: platform@400: $nodename:0: 'platform@400' does
not match '^([a-z][a-z0-9\\-]+-bus|bus|soc|axi|ahb|apb
From: Conor Dooley
The subnodes of the syscon have been added to the incorrect paths.
Rather than add them as subnodes, they were originally added to "/foo"
and a later patch moved them to "/soc/foo". Both are incorrect & they
should have been added as "/so
From: Conor Dooley
"uart" is not a node name that complies with the dt-schema.
Change the node name to "serial" to ix warnings seen during
dt-validate on a dtbdump of the virt machine such as:
/stuff/qemu/qemu.dtb: uart@1000: $nodename:0: 'uart@1000' does
From: Conor Dooley
When optional AIA PLIC support was added the to the virt machine, the
address cells property was removed leading the issues with dt-validate
on a dump from the virt machine:
/stuff/qemu/qemu.dtb: plic@c00: '#address-cells' is a required property
From schema
From: Conor Dooley
The device trees produced automatically for the virt and spike machines
fail dt-validate on several grounds. Some of these need to be fixed in
the linux kernel's dt-bindings, but others are caused by bugs in QEMU.
I mostly opted for what appeared to be the smallest change
From: Conor Dooley
"platform" is not a valid name for a bus node in dt-schema, so warnings
can be see in dt-validate on a dump of the riscv virt dtb:
/stuff/qemu/qemu.dtb: platform@400: $nodename:0: 'platform@400' does
not match '^([a-z][a-z0-9\\-]+-bus|bus|soc|axi|ahb|apb
From: Conor Dooley
When optional AIA PLIC support was added the to the virt machine, the
address cells property was removed leading the issues with dt-validate
on a dump from the virt machine:
/stuff/qemu/qemu.dtb: plic@c00: '#address-cells' is a required property
From schema
From: Conor Dooley
The subnodes of the syscon have been added to the incorrect paths.
Rather than add them as subnodes, they were originally added to "/foo"
and a later patch moved them to "/soc/foo". Both are incorrect & they
should have been added as "/so
strip
out the S and U extensions when formatting ISA strings.
Signed-off-by: Palmer Dabbelt
[Conor: rebased on 7.1.0-rc1 & slightly tweaked the commit message]
Signed-off-by: Conor Dooley
---
target/riscv/cpu.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff -
From: Conor Dooley
"platform" is not a valid name for a bus node in dt-schema, so warnings
can be see in dt-validate on a dump of the riscv virt dtb:
/stuff/qemu/qemu.dtb: platform@400: $nodename:0: 'platform@400' does
not match '^([a-z][a-z0-9\\-]+-bus|bus|soc|axi|ahb|apb
From: Conor Dooley
"uart" is not a node name that complies with the dt-schema.
Change the node name to "serial" to ix warnings seen during
dt-validate on a dtbdump of the virt machine such as:
/stuff/qemu/qemu.dtb: uart@1000: $nodename:0: 'uart@1000' does
From: Conor Dooley
The device trees produced automatically for the virt and spike machines
fail dt-validate on several grounds. Some of these need to be fixed in
the linux kernel's dt-bindings, but others are caused by bugs in QEMU.
Patch one of this series is lifted from an earlier submission
82 matches
Mail list logo
