On Mon, Jul 14, 2025 at 03:33:10PM +0200, Martin Herren wrote:
> For all riscv defconfigs that use the current default value.
>
> This is done in provision of changing the default value to the most
> common used value of 0x400.
>
> Signed-off-by: Martin Herren
> ---
>
> (no changes since v1
From: Conor Dooley
By default DEBUG_UART uses the SBI DBCN extension on S-Mode RISC-V
platforms, but the Icicle Kit's firmware doesn't support it. Since
DEBUG_UART is getting turned on automagically and this is somewhat
misleading, disable it in the Icicle kit's defconfig.
Signe
From: Conor Dooley
The loop in the icicle implementation of board_fit_config_name_match()
runs strtok() to split off the vendor portion of the compatible string
using , as the delimiter. strtok() modifies a string in place, so where
the first config and compatible do not match, the compatible
On Fri, Jul 04, 2025 at 07:01:22PM +0800, Leo Liang wrote:
>
> The PR has been sent and merged.
> Could you send a fix for this?
Yup, it may be Monday before I send it though.
signature.asc
Description: PGP signature
On Thu, Jul 03, 2025 at 06:09:53PM +0800, Leo Liang wrote:
> On Mon, Jun 23, 2025 at 12:51:36PM +0100, Conor Dooley wrote:
> > From: Conor Dooley
> >
> > The firmware on the Icicle is capable of providing a devicetree in a1 to
> > U-Boot, but until now the device
On Wed, Jun 25, 2025 at 08:14:24AM -0600, Tom Rini wrote:
> On Wed, Jun 25, 2025 at 08:36:37AM +0200, Lukasz Majewski wrote:
> > Hi Tom,
> >
> > > On Tue, Jun 24, 2025 at 10:47:00PM +0200, Lukasz Majewski wrote:
> > >
> > > > The commit e8a9521e649f
> > > > ("vf500/vf610: synchronise device trees
From: Conor Dooley
The firmware on the Icicle is capable of providing a devicetree in a1 to
U-Boot, but until now the devicetree has been packaged in a "payload" [1]
alongside U-Boot (or other bootloaders/RTOSes) and appended to the image.
The address of this appended devicetree is pl
On Mon, May 26, 2025 at 09:02:46AM +0530, Mayuresh Chitale wrote:
> On Thu, May 22, 2025 at 10:11 PM Yao Zi wrote:
> >
> > On Thu, May 22, 2025 at 12:28:18PM +0100, Conor Dooley wrote:
> > > On Wed, May 21, 2025 at 12:39:50PM -0600, Tom Rini wrote:
> > > > On
On Thu, May 22, 2025 at 04:40:57PM +, Yao Zi wrote:
> On Thu, May 22, 2025 at 12:28:18PM +0100, Conor Dooley wrote:
> > On Wed, May 21, 2025 at 12:39:50PM -0600, Tom Rini wrote:
> > > On Wed, 21 May 2025 17:50:03 +0800, Leo Liang wrote:
> > >
> > >
On Wed, May 21, 2025 at 12:39:50PM -0600, Tom Rini wrote:
> On Wed, 21 May 2025 17:50:03 +0800, Leo Liang wrote:
>
> > The following changes since commit a3e09b24ffd4429909604f1b28455b44306edbaa:
> >
> > Merge tag 'mmc-2025-05-20' of
> > https://source.denx.de/u-boot/custodians/u-boot-mmc (202
On Tue, Apr 01, 2025 at 08:44:20AM -0600, Tom Rini wrote:
> On Thu, Mar 27, 2025 at 03:58:52PM +0100, Krzysztof Kozlowski wrote:
> > On 27/03/2025 15:50, Christian Marangi wrote:
> > > On Thu, Mar 27, 2025 at 03:43:47PM +0100, Krzysztof Kozlowski wrote:
> > >> On 14/03/2025 19:59, Christian Marangi
From: Conor Dooley
Here's a U-Boot implementation of the changes I'm trying to make in
https://lore.kernel.org/all/20241002-private-unequal-33cfa6101338@spud/
that affect how the clocks are described in devicetree for PolarFire
SoC. There's been no complaints about the only part
From: Conor Dooley
The U-Boot copy of the mpfs devicetree has, in general, been neglected
somewhat in comparison to the one in Linux. Moving to OF_UPSTREAM to
keep both in sync should serve to eliminate that discrepancy.
Additionally, moving to OF_UPSTREAM will let U-Boot automatically pick
up
From: Conor Dooley
Why get a devicetree description wrong once when you can get it wrong
twice? The original mistake, which the driver supports was failing to
describe the main PLL that the "cfg" and "periph" clocks parented by.
The second mistake was describing the "c
From: Conor Dooley
The clock driver for PolarFire SoC now requires syscon and regmap
features, so imply them to preserve implication of the clock driver.
Signed-off-by: Conor Dooley
---
board/microchip/mpfs_icicle/Kconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/board/microchip
On Mon, Oct 21, 2024 at 05:34:16PM +0530, Sumit Garg wrote:
> On Fri, 18 Oct 2024 at 20:25, Conor Dooley wrote:
> > diff --git a/dts/upstream/src/riscv/Makefile
> > b/dts/upstream/src/riscv/Makefile
> > new file mode 100644
> > index 000..dd2ed0bdfbd
>
From: Conor Dooley
Here's a U-Boot implementation of the changes I'm trying to make in
https://lore.kernel.org/all/20241002-private-unequal-33cfa6101338@spud/
that affect how the clocks are described in devicetree for PolarFire
SoC. There's been no complaints about the only part
From: Conor Dooley
The clock driver for PolarFire SoC now requires syscon and regmap
features, so imply them to preserve implication of the clock driver.
Signed-off-by: Conor Dooley
---
board/microchip/mpfs_icicle/Kconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/board/microchip
From: Conor Dooley
The U-Boot copy of the mpfs devicetree has, in general, been neglected
somewhat in comparison to the one in Linux. Moving to OF_UPSTREAM to
keep both in sync should serve to eliminate that discrepancy.
Additionally, moving to OF_UPSTREAM will let U-Boot automatically pick
up
From: Conor Dooley
Why get a devicetree description wrong once when you can get it wrong
twice? The original mistake, which the driver supports was failing to
describe the main PLL that the "cfg" and "periph" clocks parented by.
The second mistake was describing the "c
On Wed, Aug 21, 2024 at 09:27:03PM +0530, Mayuresh Chitale wrote:
> On Wed, Aug 21, 2024 at 3:28 PM Conor Dooley
> wrote:
> >
> > On Tue, Aug 20, 2024 at 02:14:01PM +0200, Heinrich Schuchardt wrote:
> > > On 20.08.24 11:37, Mayuresh Chitale wrote:
> >
On Tue, Aug 20, 2024 at 02:14:01PM +0200, Heinrich Schuchardt wrote:
> On 20.08.24 11:37, Mayuresh Chitale wrote:
> > +void riscv_zicbom_init(void)
> > +{
> > + struct udevice *dev;
> > +
> > + if (!CONFIG_IS_ENABLED(RISCV_ISA_ZICBOM))
> > + return;
> > +
> > + uclass_first_device(U
On Tue, Jun 25, 2024 at 10:08:06AM +0100, Conor Dooley wrote:
> The firmware on the Icicle is capable of providing a devicetree in a1 to
> U-Boot, but until now the devicetree has been packaged in a "payload" [1]
> alongside U-Boot (or other bootloaders/RTOSes) and appended
On Fri, Jun 28, 2024 at 08:53:11AM +0300, Ilias Apalodimas wrote:
> On Thu, 27 Jun 2024 at 23:27, Conor Dooley wrote:
> > On Thu, Jun 27, 2024 at 11:50:33AM +0100, Simon Glass wrote:
> > > On Thu, 27 Jun 2024 at 10:38, Conor Dooley
> > > wrote:
> > > > O
On Fri, Jun 28, 2024 at 07:22:35AM +0100, Simon Glass wrote:
> On Thu, 27 Jun 2024 at 21:27, Conor Dooley wrote:
>
> OK, thanks for all the details. I suppose, to me, 128KB does not sound
> that constrained :-) But I can see that messing with a bloblist can
> add code. A static
On Thu, Jun 27, 2024 at 11:50:33AM +0100, Simon Glass wrote:
> On Thu, 27 Jun 2024 at 10:38, Conor Dooley wrote:
> > On Thu, Jun 27, 2024 at 09:36:49AM +0100, Simon Glass wrote:
> > > On Tue, 25 Jun 2024 at 15:34, Tom Rini wrote:
> > > > On Tue, Jun 25, 2024 at
On Thu, Jun 27, 2024 at 09:36:49AM +0100, Simon Glass wrote:
>
> On Tue, 25 Jun 2024 at 15:34, Tom Rini wrote:
> >
> > On Tue, Jun 25, 2024 at 10:08:06AM +0100, Conor Dooley wrote:
> >
> > > The firmware on the Icicle is capable of providing a devicetree in a1 t
mplete devicetree in U-Boot will be used unless
explicitly requested otherwise.
Link:
https://github.com/polarfire-soc/hart-software-services/blob/master/tools/hss-payload-generator/README.md
[1]
Signed-off-by: Conor Dooley
---
CC: Ivan Griffin
CC: Padmarao Begari
CC: Cyril Jean
CC: Tom
From: Conor Dooley
Padmarao is leaving Microchip soon, and suggested that I should take
over maintaining the Icicle in U-Boot in his stead.
Suggested-by: Padmarao Begari
Signed-off-by: Conor Dooley
---
CC: Padmarao Begari
CC: Conor Dooley
CC: Cyril Jean
CC: Tom Rini
CC: u-boot
On Fri, Jun 14, 2024 at 12:14:37PM +0100, Conor Dooley wrote:
> Hey,
I forgot a word in $subject, should have said PCI issues. I added it.
>
> After going from Vendor SPL/OpenSBI/U-Boot to OpenSBI v1.4++ plus
> v2024.07-rc4 SPL/U-Boot I ran into a boot loop problem relating to
>
Hey,
After going from Vendor SPL/OpenSBI/U-Boot to OpenSBI v1.4++ plus
v2024.07-rc4 SPL/U-Boot I ran into a boot loop problem relating to
PCI:
U-Boot 2024.07-rc4 (Jun 13 2024 - 15:09:34 +0100)
CPU: sifive,u74-mc
Model: StarFive VisionFive 2 v1.2A
DRAM: 4
On Wed, Jun 05, 2024 at 08:35:15AM -0600, Tom Rini wrote:
> On Wed, Jun 05, 2024 at 01:56:13AM +, Hal Feng wrote:
> > > On 04.06.24 04:32, E Shattow wrote:
> > > Hi Hal,
> > >
> > > Instead of manual dt-bindings sync can we please adopt OF_UPSTREAM for
> > > JH7110 ?
> >
> > Yeah, I will try
From: Conor Dooley
A given AMP configuration for a board may make either one, or neither
of, the ethernet ports available to U-Boot. The Icicle's init code will
fail if mac1 is not present, so move it to the optional approach taken
for mac0.
Signed-off-by: Conor Dooley
---
board/micr
From: Conor Dooley
Node offsets returned by libfdt can contain negative error numbers, so
the variable type should be "int". As things stand, if the ethernet
nodes are not found in the early init callback, the if (node < 0) tests
pass and the code errors out while trying to set
From: Conor Dooley
Two fixes for issues that I spotted today while looking into passing a
minimal dtb to U-Boot from the first bootloader stage. This minimal dtb
had no ethernet nodes, and the code in this patches fell over :\
Cheers,
Conor.
---
CC: Padmarao Begari
CC: Cyril Jean
CC: Tom Rini
On Tue, Apr 23, 2024 at 09:52:06AM -0300, Daniel Henrique Barboza wrote:
>
>
> On 4/23/24 09:41, Conor Dooley wrote:
> > On Tue, Apr 23, 2024 at 01:34:42PM +0800, Leo Liang wrote:
> > > On Mon, Apr 22, 2024 at 04:43:59PM -0300, Daniel Henrique Barboza wrote
On Tue, Apr 23, 2024 at 01:34:42PM +0800, Leo Liang wrote:
> On Mon, Apr 22, 2024 at 04:43:59PM -0300, Daniel Henrique Barboza wrote:
> > [EXTERNAL MAIL]
> >
> > Hi,
> >
> > In QEMU we have a 'max' type CPU that implements (almost) all extensions
> > that QEMU
> > is able to emulate. Recently, i
From: Conor Dooley
A new property has been added, with an extensive rationale at [1], that
can be used in place of "riscv,isa" to indicate what extensions are
supported by a given platform that is a list of strings rather than a
single string. There are some differences between the ne
From: Conor Dooley
cpu_get_desc() for the RISC-V CPU currently reads "riscv,isa" to get
the description, but it is no longer a required property and cannot be
assummed to always be present, as the new "riscv,isa-extensions" and
"riscv,isa-base" properties may
From: Conor Dooley
This would have just been a single patch (the second one), but as I
reported a while back there's a problem with extension detection when
the ISA string exceeds 32 characters:
https://lore.kernel.org/u-boot/20240221-daycare-reliably-8ec86f95fe71@spud/
The first patch
On Tue, Mar 12, 2024 at 05:59:44PM +0800, Leo Liang wrote:
> On Sun, Mar 10, 2024 at 01:56:45PM +0800, Kongyang Liu wrote:
> > Add ethernet node for cv1800b SoC
> >
> > Signed-off-by: Kongyang Liu
> > ---
> >
> > arch/riscv/dts/cv18xx.dtsi | 6 ++
> > 1 file changed, 6 insertions(+)
>
> Hi
On Fri, Mar 01, 2024 at 01:54:13PM -0500, Tom Rini wrote:
> On Fri, Mar 01, 2024 at 01:32:53PM +0000, Conor Dooley wrote:
> > > > > > > > > On Wed, 28 Feb 2024 at 18:40, Tom Rini
> > > > > > > > > wrote:
> > > > > > >
; Fixes: dfe08374943c ("risc-v: implement DBCN based debug console")
> Signed-off-by: Heinrich Schuchardt
This also appears to fix the inconsistent boot issues that I've been
seeing since I reported:
https://lore.kernel.org/u-boot/20240122-finicky-ancient-797ba048f927@spud/
Tested-by
ot the implementation ID.
>
> * Show the correct number
> * Use a hexadecimal output format
> * Add a missing line feed
>
> Signed-off-by: Heinrich Schuchardt
Reviewed-by: Conor Dooley
Thanks,
Conor.
> cmd/riscv/sbi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
e to a more recent version because of space
constraints mostly. Since the bug prevents using some forms of suspend,
we moved to a custom implementation ID so that there could be
differentiation.
Reviewed-by: Conor Dooley
Cheers,
Conor.
> ---
> cmd/riscv/sbi.c | 1 +
> 1 file changed, 1 in
On Tue, Mar 05, 2024 at 09:10:59AM +0100, Heinrich Schuchardt wrote:
> On 3/5/24 08:54, Conor Dooley wrote:
> > On Tue, Mar 05, 2024 at 08:34:20AM +0100, Heinrich Schuchardt wrote:
> > > On 3/5/24 00:28, Conor Dooley wrote:
> > > > From: Conor Dooley
> > >
On Tue, Mar 05, 2024 at 08:34:20AM +0100, Heinrich Schuchardt wrote:
> On 3/5/24 00:28, Conor Dooley wrote:
> > From: Conor Dooley
> According to
> https://github.com/riscv/riscv-isa-manual/blob/main/src/naming.adoc the
> ISA string is case insensitive. Why can we assume her
From: Conor Dooley
The first multi-letter extension after the single-letter extensions does
not have to be preceded by an underscore, which could cause the parser
to mistakenly find a single-letter extension after the start of the
multi-letter portion of the string.
Three letters precede multi
Apologies for the delay replying here.
On Thu, Feb 22, 2024 at 01:36:41PM +0100, Heinrich Schuchardt wrote:
> On 21.02.24 18:59, Conor Dooley wrote:
> > I mentioned this last night to Heinrich on IRC, supports_extension() is
> > broken for ISA strings longer than 32 characters
Hey,
Replying here because this is only version of this in my inbox atm.
On Fri, Mar 01, 2024 at 10:17:35AM +0100, Sébastien Szymanski wrote:
> On 3/1/24 07:02, Sumit Garg wrote:
> > On Thu, 29 Feb 2024 at 19:31, Tom Rini wrote:
> > > On Thu, Feb 29, 2024 at 08:42:42AM -0500, Tom Rini wrote:
> >
Yo,
I mentioned this last night to Heinrich on IRC, supports_extension() is
broken for ISA strings longer than 32 characters. M-Mode U-Boot doesn't
parse a devicetree, so this doesn't apply there, but for S-mode
supports_extension() looks like:
static inline bool supports_extension(char ext)
{
On Tue, Jan 23, 2024 at 01:03:00PM -0500, Tom Rini wrote:
> On Tue, Jan 23, 2024 at 11:27:57AM +0000, Conor Dooley wrote:
> > On Mon, Jan 22, 2024 at 06:55:01PM +0000, Conor Dooley wrote:
> > > On Mon, Jan 22, 2024 at 01:47:17PM -0500, Tom Rini wrote:
> > > > On M
On Mon, Jan 22, 2024 at 06:55:01PM +, Conor Dooley wrote:
> On Mon, Jan 22, 2024 at 01:47:17PM -0500, Tom Rini wrote:
> > On Mon, Jan 22, 2024 at 06:36:31PM +0000, Conor Dooley wrote:
> > > Hey,
> > >
> > > On Tue, Jan 16, 2024 at 01:48:06PM +
On Mon, Jan 22, 2024 at 01:47:17PM -0500, Tom Rini wrote:
> On Mon, Jan 22, 2024 at 06:36:31PM +0000, Conor Dooley wrote:
> > Hey,
> >
> > On Tue, Jan 16, 2024 at 01:48:06PM +, Conor Dooley wrote:
> > > Yo,
> > >
> > > On Wed, Jan
Hey,
On Tue, Jan 16, 2024 at 01:48:06PM +, Conor Dooley wrote:
> Yo,
>
> On Wed, Jan 03, 2024 at 06:49:19PM -0700, Simon Glass wrote:
> > Standard passage provides for a bloblist to be passed from one firmware
> > phase to the next. That can be used to pass the dev
Yo,
On Wed, Jan 03, 2024 at 06:49:19PM -0700, Simon Glass wrote:
> Standard passage provides for a bloblist to be passed from one firmware
> phase to the next. That can be used to pass the devicetree along as well.
> Add an option to support this.
>
> Tests for this will be added as part of the U
On Fri, Dec 22, 2023 at 04:38:01PM +0100, Krzysztof Kozlowski wrote:
> On 22/12/2023 14:43, Sumit Garg wrote:
> > On Fri, 22 Dec 2023 at 13:48, Krzysztof Kozlowski
> > wrote:
> >>
> >> On 22/12/2023 07:12, Sumit Garg wrote:
> >>> Changes in v2:
> >>> --
> >>> - Patch #1: excluded gitab
On Fri, Dec 15, 2023 at 08:37:43AM -0500, Tom Rini wrote:
> On Fri, Dec 15, 2023 at 08:50:51AM +0100, Krzysztof Kozlowski wrote:
> > On 14/12/2023 20:48, Rob Herring wrote:
> > >>
> > >> I think some of the important questions to ask are, how often / likely
> > >> are the breakages to occur? It see
On Fri, Dec 08, 2023 at 09:39:27AM +, ff wrote:
>
>
> Le 7 déc. 2023 à 21:31, Conor Dooley a écrit :
>
> What on earth has happened here with quoting? Please fix your mail
> client man, this mail is a mess to read.
>
> Conor: Hopefully I have now fixed MacOS Mail
What on earth has happened here with quoting? Please fix your mail
client man, this mail is a mess to read.
On Thu, Dec 07, 2023 at 08:24:01PM +, ff wrote:
>
>
> Le 7 déc. 2023 à 19:51, Rob Herring a écrit :
>
> On Thu, Dec 7, 2023 at 2:08 AM ff wrote:
>
>
>
> Le 6 déc. 2023 à 21:42,
On Tue, Nov 07, 2023 at 06:23:05PM -0500, Tom Rini wrote:
> On Tue, Nov 07, 2023 at 11:12:16PM +0000, Conor Dooley wrote:
> > +CC Palmer
> >
> > On Tue, Nov 07, 2023 at 05:38:37PM -0500, Tom Rini wrote:
> > > On Tue, Nov 07, 2023 at 10:27:50PM +, Conor Dooley
+CC Palmer
On Tue, Nov 07, 2023 at 05:38:37PM -0500, Tom Rini wrote:
> On Tue, Nov 07, 2023 at 10:27:50PM +0000, Conor Dooley wrote:
> > On Tue, Nov 07, 2023 at 05:10:23PM -0500, Tom Rini wrote:
> >
> >
> > > further clarify or not
> > > the RISC-V ISA thi
On Tue, Nov 07, 2023 at 05:10:23PM -0500, Tom Rini wrote:
> further clarify or not
> the RISC-V ISA thing that's elsewhere in this thread (and part of the
> kernel, not a U-Boot thing).
TBH, this a bit fragmented across threads, and as someone that hasn't
been following it it's a bit difficult t
Yo,
Since you sent it to me, I may as well comment...
On Fri, Nov 03, 2023 at 05:03:25PM +0100, Michal Simek wrote:
> MicroBlaze V is new AMD/Xilinx soft-core 32bit RISC-V processor IP.
> It is hardware compatible with classic MicroBlaze processor.
>
> The patch contains initial wiring and confi
Hey Heinrich,
On Fri, Jul 28, 2023 at 05:48:31PM +0200, Heinrich Schuchardt wrote:
> Add more detail to the description of U-Boot boot phases:
>
> * describe which steps are optional
> * mentions alternative boot flows
>
> Signed-off-by: Heinrich Schuchardt
> ---
> doc/develop/spl.rst | 13 +++
From: Conor Dooley
intro
=
When the RISC-V dt-bindings were accepted upstream in Linux, the base
ISA etc had yet to be ratified. By the ratification of the base ISA,
incompatible changes had snuck into the specifications - for example the
Zicsr and Zifencei extensions were spun out of the
On Sat, Jul 01, 2023 at 01:01:40PM +0200, Andrew Jones wrote:
> On Fri, Jun 30, 2023 at 07:04:04PM +0100, Conor Dooley wrote:
> > From: Conor Dooley
> ...
> > +oneOf:
> > + - required:
> > + - riscv,isa
> > + - required:
> > + - riscv,isa-ba
From: Conor Dooley
intro
=
When the RISC-V dt-bindings were accepted upstream in Linux, the base
ISA etc had yet to be ratified. By the ratification of the base ISA,
incompatible changes had snuck into the specifications - for example the
Zicsr and Zifencei extensions were spun out of the
Been implementing feedback, so going back through this
On Tue, Jun 27, 2023 at 12:30:25PM +0100, Conor Dooley wrote:
> On Mon, Jun 26, 2023 at 11:35:10PM -0700, Atish Patra wrote:
> > On Mon, Jun 26, 2023 at 5:40 PM Stefan O'Rear wrote:
> > > On Mon, Jun 26, 2023, at 6:10
Hey Atish, Stefan,
On Mon, Jun 26, 2023 at 11:35:10PM -0700, Atish Patra wrote:
> On Mon, Jun 26, 2023 at 5:40 PM Stefan O'Rear wrote:
> > On Mon, Jun 26, 2023, at 6:10 AM, Conor Dooley wrote:
> > > Off-list, some of the RVI folks have committed to shoring up the wording
On Mon, Jun 26, 2023 at 11:08:43PM +0530, Anup Patel wrote:
> On Mon, Jun 26, 2023 at 3:42 PM Conor Dooley
> wrote:
> > acpi
> >
> >
> > The current ACPI ECR is based on having a single ISA string unfortunately,
> > but ideally ACPI will move to anot
a Clarke
CC: Rick Chen
CC: Leo
CC: Oleksii
CC: linux-ri...@lists.infradead.org
CC: qemu-ri...@nongnu.org
CC: u-boot@lists.denx.de
CC: devicet...@vger.kernel.org
CC: linux-ker...@vger.kernel.org
Reviewed-by: Palmer Dabbelt
Acked-by: Palmer Dabbelt
Signed-off-by: Conor Dooley
---
Changes in v3:
- Per Rob&
On Thu, Jun 22, 2023 at 11:25:35AM -0700, Palmer Dabbelt wrote:
> Reviewed-by: Palmer Dabbelt
> Acked-by: Palmer Dabbelt
>
> I'm not wed to any particular encoding for the properties, IMO that's more
> of a decision for the DT folks. IMO the important bit is to just get away
> from ISA strings
art of the icicle's default configuration
is removed.
Reviewed-by: Padmarao Begari
Tested-by: Padmarao Begari
Signed-off-by: Conor Dooley
---
arch/riscv/dts/mpfs-icicle-kit-fabric.dtsi| 71 +++
arch/riscv/dts/mpfs-icicle-kit.dts| 190 +---
arch/riscv/dts/mpfs.dtsi
Begari
Signed-off-by: Conor Dooley
---
board/microchip/mpfs_icicle/mpfs_icicle.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/board/microchip/mpfs_icicle/mpfs_icicle.c
b/board/microchip/mpfs_icicle/mpfs_icicle.c
index e74c9fb03c..0f5f82924e 100644
--- a
The original names picked for the DT doesn't match Linux's naming scheme
and it was renamed there a while ago. Rename it in U-Boot to allow
easily syncing dts between the two projects.
Reviewed-by: Rick Chen
Reviewed-by: Padmarao Begari
Signed-off-by: Conor Dooley
---
arch/riscv/dt
rework the
mac address setting code as it'll be needed to support another board.
Cheers,
Conor.
Changes in v2:
- Fix address in error print in 3/3
Conor Dooley (3):
riscv: dts: drop microchip from dts filenames
riscv: dts: sync mpfs-icicle devicetree with linux
board: microchip: set
On Tue, Jun 13, 2023 at 05:35:58AM +, padmarao.beg...@microchip.com wrote:
> On Wed, 2023-06-07 at 11:06 +0100, Conor Dooley wrote:
> > @@ -123,6 +123,15 @@ int board_late_init(void)
> >
> > mac_addr[5] = device_serial_number[0] + 1;
> >
> > + n
On Tue, Jun 13, 2023 at 07:28:34AM -0600, Rob Herring wrote:
> On Mon, Jun 12, 2023 at 3:23 PM Conor Dooley wrote:
> > 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, Ma
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 03:12:12PM +0100, Conor Dooley wrote:
> > > On Thu, May 18, 2023 at 10:42:34PM +
On Fri, Jun 09, 2023 at 08:03:44AM -0600, Rob Herring wrote:
> Nope, vendor prefixes don't go in node names. That's not explicit
> anywhere, but goes against using generic node names.
Yeah, that makes sense.
> Also, note that looking at the DT spec, there's already prior art here
> with PPC. See
On Thu, Jun 08, 2023 at 01:15:37PM -0600, Rob Herring wrote:
> On Tue, May 30, 2023 at 03:12:12PM +0100, Conor Dooley wrote:
> > On Thu, May 18, 2023 at 10:42:34PM +0100, Conor Dooley wrote:
> > > On Thu, May 18, 2023 at 02:30:53PM -0400, Sean Anderson 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
> > riscv,isa-extensions as an exception to the rules preventing vendor
> >
From: Conor Dooley
intro
=
When the RISC-V dt-bindings were accepted upstream in Linux, the base
ISA etc had yet to be ratified. By the ratification of the base ISA,
incompatible changes had snuck into the specifications - for example the
Zicsr and Zifencei extensions were spun out of the
The dts sync from Linux leaves mac0/ethernet1 enabled on icicle, but
U-Boot does not currently set a mac address for it. Expand on the code
which currently sets the mac for mac1/ethernet0 to optionally set the
mac address for the second ethernet.
Signed-off-by: Conor Dooley
---
board/microchip
art of the icicle's default configuration
is removed.
Signed-off-by: Conor Dooley
---
arch/riscv/dts/mpfs-icicle-kit-fabric.dtsi| 71 +++
arch/riscv/dts/mpfs-icicle-kit.dts| 190 +---
arch/riscv/dts/mpfs.dtsi | 442 --
.../dt-bindi
The original names picked for the DT doesn't match Linux's naming scheme
and it was renamed there a while ago. Rename it in U-Boot to allow
easily syncing dts between the two projects.
Signed-off-by: Conor Dooley
---
arch/riscv/dts/Makefile |
rework the
mac address setting code as it'll be needed to support another board.
Cheers,
Conor.
Conor Dooley (3):
riscv: dts: drop microchip from dts filenames
riscv: dts: sync mpfs-icicle devicetree with linux
board: microchip: set mac address for ethernet1 on icic
On Thu, May 18, 2023 at 10:42:34PM +0100, Conor Dooley wrote:
> On Thu, May 18, 2023 at 02:30:53PM -0400, Sean Anderson wrote:
> >
> > Why not just have something like
> >
> > mycpu {
> > ...
> > riscv,isa {
> > i;
> >
On Fri, May 26, 2023 at 09:34:32AM +0200, Torsten Duwe wrote:
> On Wed, 24 May 2023 11:19:48 +0100
> Conor Dooley wrote:
>
> > On Wed, May 24, 2023 at 05:00:02PM +0800, Xingyu Wu wrote:
> > > On 2023/5/23 19:28, Conor Dooley wrote:
> > > > On Tue, May 23, 20
On Wed, May 24, 2023 at 05:00:02PM +0800, Xingyu Wu wrote:
> On 2023/5/23 19:28, Conor Dooley wrote:
> > On Tue, May 23, 2023 at 01:10:06PM +0200, Torsten Duwe wrote:
> >> On Tue, 23 May 2023 09:28:39 +0100
> >> Conor Dooley wrote:
> >>
> >> > On
On Tue, May 23, 2023 at 01:10:06PM +0200, Torsten Duwe wrote:
> On Tue, 23 May 2023 09:28:39 +0100
> Conor Dooley wrote:
>
> > On Tue, May 23, 2023 at 10:56:43AM +0800, Xingyu Wu wrote:
> > > On 2023/5/19 22:16, Conor Dooley wrote:
> > > > On Fri, May 19, 20
On Thu, May 18, 2023 at 02:30:53PM -0400, Sean Anderson wrote:
> On 5/18/23 10:06, Conor Dooley wrote:
> > On Thu, May 18, 2023 at 07:13:15PM +0530, Anup Patel wrote:
> >> On Thu, May 18, 2023 at 4:02 PM Andrew Jones
> >> wrote:
> >> > On Thu, May 18, 2023
On Thu, May 18, 2023 at 07:41:17AM -0700, Palmer Dabbelt wrote:
> On Thu, 18 May 2023 07:06:17 PDT (-0700), Conor Dooley wrote:
> > On Thu, May 18, 2023 at 07:13:15PM +0530, Anup Patel wrote:
> > > On Thu, May 18, 2023 at 4:02 PM Andrew Jones
> > > wrote:
> >
On Thu, May 18, 2023 at 07:13:15PM +0530, Anup Patel wrote:
> On Thu, May 18, 2023 at 4:02 PM Andrew Jones wrote:
> > On Thu, May 18, 2023 at 09:58:30AM +0100, Conor Dooley wrote:
> > > - riscv,isa:
> > > -description:
> > > - Identifies the specific
On Thu, May 18, 2023 at 12:31:51PM +0200, Andrew Jones wrote:
> > + # Additional Standard Extensions, sorted by category then alphabetically
>
> Can we just do pure alphabetically? And the single-letter extensions above
> don't have a "sorted by" comment above them. I guess they need one, or
> ma
Hey Drew,
On Thu, May 18, 2023 at 12:31:51PM +0200, Andrew Jones wrote:
> On Thu, May 18, 2023 at 09:58:30AM +0100, Conor Dooley wrote:
> > - riscv,isa:
> > -description:
> > - Identifies the specific RISC-V instruction set architecture
> > - suppor
.org
CC: u-boot@lists.denx.de
CC: devicet...@vger.kernel.org
CC: linux-ker...@vger.kernel.org
Signed-off-by: Conor Dooley
---
I've tried to CC a few folks here that would care about this, but I am
sure there are more. I'll go cross-post it to sw-dev, if it allows me to
post there...
---
..
mething a fair hackier & probably should have
already sent something by now :/ What you have here is either the
same as what we have, or an improvement:
Reviewed-by: Conor Dooley
Thanks for doing this.
signature.asc
Description: PGP signature
On Thu, Mar 16, 2023 at 10:53:29AM +0800, Yanhong Wang wrote:
> Add initial device tree for the JH7110 RISC-V SoC.
>
> Signed-off-by: Yanhong Wang
> Tested-by: Conor Dooley
> + S7_0: cpu@0 {
> + compatible = "sifive,s7", "riscv&q
1 - 100 of 142 matches
Mail list logo
