RE: [PATCH v5 0/5] add DM based reset driver for SiFive SoC's
Hi Rick,
> -Original Message-
> From: Sagar Kadam
> Sent: Wednesday, July 29, 2020 3:06 PM
> To: u-boot@lists.denx.de
> Cc: r...@andestech.com; Paul Walmsley ( Sifive) ;
> pal...@dabbelt.com; anup.pa...@wdc.com; atish.pa...@wdc.com;
> lu...@denx.de; Pragnesh Patel ;
> bin.m...@windriver.com; ja...@amarulasolutions.com; s...@chromium.org;
> twoer...@gmail.com; mbrug...@suse.com; eugeniy.palt...@synopsys.com;
> sean...@gmail.com; patr...@blueri.se; nsaenzjulie...@suse.de;
> weijie@mediatek.com; feste...@gmail.com; Sagar Kadam
>
> Subject: [PATCH v5 0/5] add DM based reset driver for SiFive SoC's
>
> The FU540-C000 support in U-Boot is missing DM based reset driver, and is
> handling reset's to sub-system within the prci driver itself.
> The series here adds a generic DM reset driver for SiFive SoC's so as to
> leverage
> the U-Boot's reset framework and binds the reset driver with prci driver.
> The PRCI driver takes care of triggering the consumers reset signals
> appropriately.
>
> Patch 1: Add necessary dt indexes for device reset register.
> Patch 2: Update macro's to use common dt indexes from binding header.
> Patch 3: Add reset producer and consumer entries within the device tree.
> Patch 4: Add reset dm driver and bind it within prci module.
> Patch 5: Add Kconfig, Makefile entries and enable the driver
>
> This series is re-based on u-boot-riscv top commit 3b191c56c841 ("Merge
> branch '2020-07-28-Kconfig-migrations'")
>
> History:
> ==
> V5:
> -Rebased the series on u-boot-riscv/master.
>
A gentle reminder to pull in this series.
Thanks & BR,
Sagar
> V4:
> -Rebased the series to u-boot/master.
>
> V3:
> -Add reset indexes in separate dt binding header instead of updating the
> clock
> dt binding header which is synced from Linux
>
> V2:
> -Removed extra character in commit log of 2nd patch
>
> V1:
> -Base version.
>
> Sagar Shrikant Kadam (5):
> dt-bindings: prci: add indexes for reset signals available in prci
> fu540: prci: use common reset indexes defined in binding header
> fu540: dtsi: add reset producer and consumer entries
> sifive: reset: add DM based reset driver for SiFive SoC's
> configs: reset: fu540: enable dm reset framework for SiFive
>
> arch/riscv/dts/fu540-c000-u-boot.dtsi | 12 +++
> arch/riscv/include/asm/arch-fu540/reset.h | 13 +++
> configs/sifive_fu540_defconfig| 2 +
> drivers/clk/sifive/fu540-prci.c | 90 ++--
> drivers/reset/Kconfig | 9 ++
> drivers/reset/Makefile| 1 +
> drivers/reset/reset-sifive.c | 118
> ++
> include/dt-bindings/reset/sifive-fu540-prci.h | 19 +
> 8 files changed, 239 insertions(+), 25 deletions(-) create mode 100644
> arch/riscv/include/asm/arch-fu540/reset.h
> create mode 100644 drivers/reset/reset-sifive.c create mode 100644
> include/dt-bindings/reset/sifive-fu540-prci.h
>
> --
> 2.7.4
RE: [PATCH v4 0/5] add DM based reset driver for SiFive SoC's
Hi Rick,
> -Original Message-
> From: Rick Chen
> Sent: Wednesday, July 29, 2020 7:26 AM
> To: Sagar Kadam
> Cc: U-Boot Mailing List ; Paul Walmsley ( Sifive)
> ; Palmer Dabbelt ; Anup
> Patel ; Atish Patra ; Lukasz
> Majewski ; Pragnesh Patel ;
> bin.m...@windriver.com; Jagan Teki ;
> Simon Glass ; Trevor Woerner ;
> patr...@blueri.se; mbrug...@suse.com; Eugeniy Paltsev
> ; weijie@mediatek.com;
> nsaenzjulie...@suse.de; feste...@gmail.com; Sean Anderson
> ; rick ; Alan Kao
>
> Subject: Re: [PATCH v4 0/5] add DM based reset driver for SiFive SoC's
>
> [External Email] Do not click links or attachments unless you recognize the
> sender and know the content is safe
>
> Hi Sagar
>
> > From: Sagar Kadam [mailto:sagar.ka...@sifive.com]
> > Sent: Tuesday, July 28, 2020 11:19 PM
> > To: u-boot@lists.denx.de
> > Cc: Rick Jian-Zhi Chen(陳建志); Paul Walmsley ( Sifive);
> > pal...@dabbelt.com; anup.pa...@wdc.com; atish.pa...@wdc.com;
> > lu...@denx.de; Pragnesh Patel; bin.m...@windriver.com;
> > ja...@amarulasolutions.com; s...@chromium.org; twoer...@gmail.com;
> > patr...@blueri.se; mbrug...@suse.com; eugeniy.palt...@synopsys.com;
> > weijie@mediatek.com; nsaenzjulie...@suse.de;
> feste...@gmail.com;
> > sean...@gmail.com
> > Subject: RE: [PATCH v4 0/5] add DM based reset driver for SiFive SoC's
> >
> > Hello Rick,
> >
> > > -Original Message-
> > > From: Sagar Kadam
> > > Sent: Monday, July 27, 2020 8:56 PM
> > > To: u-boot@lists.denx.de
> > > Cc: r...@andestech.com; Paul Walmsley ( Sifive)
> > > ; pal...@dabbelt.com;
> anup.pa...@wdc.com;
> > > atish.pa...@wdc.com; lu...@denx.de; Pragnesh Patel
> > > ; bin.m...@windriver.com;
> > > ja...@amarulasolutions.com; s...@chromium.org;
> twoer...@gmail.com;
> > > patr...@blueri.se; mbrug...@suse.com; eugeniy.palt...@synopsys.com;
> > > weijie@mediatek.com; nsaenzjulie...@suse.de;
> feste...@gmail.com;
> > > sean...@gmail.com
> > > Subject: RE: [PATCH v4 0/5] add DM based reset driver for SiFive
> > > SoC's
> > >
> > > Hi Rick,
> > > > -Original Message-
> > > > From: Sagar Kadam
> > > > Sent: Friday, July 24, 2020 2:17 PM
> > > > To: u-boot@lists.denx.de
> > > > Cc: r...@andestech.com; Paul Walmsley ( Sifive)
> > > > ; pal...@dabbelt.com;
> > > anup.pa...@wdc.com;
> > > > atish.pa...@wdc.com; lu...@denx.de; Pragnesh Patel
> > > > ; bin.m...@windriver.com;
> > > > ja...@amarulasolutions.com; s...@chromium.org;
> twoer...@gmail.com;
> > > > patr...@blueri.se; mbrug...@suse.com;
> > > > eugeniy.palt...@synopsys.com; weijie@mediatek.com;
> > > > nsaenzjulie...@suse.de;
> > > feste...@gmail.com;
> > > > sean...@gmail.com; Sagar Kadam
> > > > Subject: [PATCH v4 0/5] add DM based reset driver for SiFive SoC's
> > > >
> > > > The FU540-C000 support in U-Boot is missing DM based reset driver,
> > > > and is handling reset's to sub-system within the prci driver itself.
> > > > The series here adds a generic DM reset driver for SiFive SoC's so
> > > > as to leverage the U-Boot's reset framework and binds the reset
> > > > driver with prci driver.
> > > > The PRCI driver takes care of triggering the consumers reset
> > > > signals appropriately.
> > > >
> > > > Patch 1: Add necessary dt indexes for device reset register.
> > > > Patch 2: Update macro's to use common dt indexes from binding
> header.
> > > > Patch 3: Add reset producer and consumer entries within the device
> tree.
> > > > Patch 4: Add reset dm driver and bind it within prci module.
> > > > Patch 5: Add Kconfig, Makefile entries and enable the driver
> > > >
> > > > This series is re-based on mainline U-Boot commit 5d3a21df6694
> > > > ("Merge
> > > tag
> > > > 'dm-pull-20jul20' of git://git.denx.de/u-boot-dm") and depends on
> > > > [1]
> > > >
> > > > [1] https://patchwork.ozlabs.org/project/uboot/list/?series=190862
> > > >
> > >
> > > I have rebased this series on u-boot/master.
> > > Can you please pull it and let me know if any issues are there.
> > >
> > It seems that u-boot/master is moved ahead and the commit on which this
> series was based is reverted "Revert "Merge tag 'dm-pull-20jul20' of
> git://git.denx.de/u-boot-dm"&
RE: [PATCH v4 0/5] add DM based reset driver for SiFive SoC's
Hi Simon,
> -Original Message-
> From: Simon Glass
> Sent: Wednesday, July 29, 2020 12:28 AM
> To: Sagar Kadam
> Cc: u-boot@lists.denx.de; r...@andestech.com; Paul Walmsley ( Sifive)
> ; pal...@dabbelt.com; anup.pa...@wdc.com;
> atish.pa...@wdc.com; lu...@denx.de; Pragnesh Patel
> ; bin.m...@windriver.com;
> ja...@amarulasolutions.com; twoer...@gmail.com; patr...@blueri.se;
> mbrug...@suse.com; eugeniy.palt...@synopsys.com;
> weijie@mediatek.com; nsaenzjulie...@suse.de; feste...@gmail.com;
> sean...@gmail.com
> Subject: Re: [PATCH v4 0/5] add DM based reset driver for SiFive SoC's
>
> [External Email] Do not click links or attachments unless you recognize the
> sender and know the content is safe
>
> Hi Sagar,
>
> On Tue, 28 Jul 2020 at 09:19, Sagar Kadam wrote:
> >
> > Hello Rick,
> >
> > > -Original Message-
> > > From: Sagar Kadam
> > > Sent: Monday, July 27, 2020 8:56 PM
> > > To: u-boot@lists.denx.de
> > > Cc: r...@andestech.com; Paul Walmsley ( Sifive)
> > > ; pal...@dabbelt.com;
> anup.pa...@wdc.com;
> > > atish.pa...@wdc.com; lu...@denx.de; Pragnesh Patel
> > > ; bin.m...@windriver.com;
> > > ja...@amarulasolutions.com; s...@chromium.org;
> twoer...@gmail.com;
> > > patr...@blueri.se; mbrug...@suse.com; eugeniy.palt...@synopsys.com;
> > > weijie@mediatek.com; nsaenzjulie...@suse.de;
> feste...@gmail.com;
> > > sean...@gmail.com
> > > Subject: RE: [PATCH v4 0/5] add DM based reset driver for SiFive
> > > SoC's
> > >
> > > Hi Rick,
> > > > -Original Message-
> > > > From: Sagar Kadam
> > > > Sent: Friday, July 24, 2020 2:17 PM
> > > > To: u-boot@lists.denx.de
> > > > Cc: r...@andestech.com; Paul Walmsley ( Sifive)
> > > > ; pal...@dabbelt.com;
> > > anup.pa...@wdc.com;
> > > > atish.pa...@wdc.com; lu...@denx.de; Pragnesh Patel
> > > > ; bin.m...@windriver.com;
> > > > ja...@amarulasolutions.com; s...@chromium.org;
> twoer...@gmail.com;
> > > > patr...@blueri.se; mbrug...@suse.com;
> > > > eugeniy.palt...@synopsys.com; weijie@mediatek.com;
> > > > nsaenzjulie...@suse.de;
> > > feste...@gmail.com;
> > > > sean...@gmail.com; Sagar Kadam
> > > > Subject: [PATCH v4 0/5] add DM based reset driver for SiFive SoC's
> > > >
> > > > The FU540-C000 support in U-Boot is missing DM based reset driver,
> > > > and is handling reset's to sub-system within the prci driver itself.
> > > > The series here adds a generic DM reset driver for SiFive SoC's so
> > > > as to leverage the U-Boot's reset framework and binds the reset
> > > > driver with prci driver.
> > > > The PRCI driver takes care of triggering the consumers reset
> > > > signals appropriately.
> > > >
> > > > Patch 1: Add necessary dt indexes for device reset register.
> > > > Patch 2: Update macro's to use common dt indexes from binding
> header.
> > > > Patch 3: Add reset producer and consumer entries within the device
> tree.
> > > > Patch 4: Add reset dm driver and bind it within prci module.
> > > > Patch 5: Add Kconfig, Makefile entries and enable the driver
> > > >
> > > > This series is re-based on mainline U-Boot commit 5d3a21df6694
> > > > ("Merge
> > > tag
> > > > 'dm-pull-20jul20' of git://git.denx.de/u-boot-dm") and depends on
> > > > [1]
> > > >
> > > > [1] https://patchwork.ozlabs.org/project/uboot/list/?series=190862
> > > >
> > >
> > > I have rebased this series on u-boot/master.
> > > Can you please pull it and let me know if any issues are there.
> > >
> > It seems that u-boot/master is moved ahead and the commit on which
> > this series was based is reverted "Revert "Merge tag 'dm-pull-20jul20' of
> git://git.denx.de/u-boot-dm""
> > and will again conflict considering other patch's that are merged in u-
> boot/master.
> > I can rebase it again, but would like to know what you would prefer me
> > to rebase on u-boot/master or u-boot-riscv/master?
>
> Can you take another look? The DM stuff landed again yesterday.
>
Yes sure, I will revisit it again.
BR,
Sagar
> Regards,
> Simon
RE: [PATCH v4 0/5] add DM based reset driver for SiFive SoC's
Hello Rick,
> -Original Message-
> From: Sagar Kadam
> Sent: Monday, July 27, 2020 8:56 PM
> To: u-boot@lists.denx.de
> Cc: r...@andestech.com; Paul Walmsley ( Sifive)
> ; pal...@dabbelt.com; anup.pa...@wdc.com;
> atish.pa...@wdc.com; lu...@denx.de; Pragnesh Patel
> ; bin.m...@windriver.com;
> ja...@amarulasolutions.com; s...@chromium.org; twoer...@gmail.com;
> patr...@blueri.se; mbrug...@suse.com; eugeniy.palt...@synopsys.com;
> weijie@mediatek.com; nsaenzjulie...@suse.de; feste...@gmail.com;
> sean...@gmail.com
> Subject: RE: [PATCH v4 0/5] add DM based reset driver for SiFive SoC's
>
> Hi Rick,
> > -Original Message-
> > From: Sagar Kadam
> > Sent: Friday, July 24, 2020 2:17 PM
> > To: u-boot@lists.denx.de
> > Cc: r...@andestech.com; Paul Walmsley ( Sifive)
> > ; pal...@dabbelt.com;
> anup.pa...@wdc.com;
> > atish.pa...@wdc.com; lu...@denx.de; Pragnesh Patel
> > ; bin.m...@windriver.com;
> > ja...@amarulasolutions.com; s...@chromium.org; twoer...@gmail.com;
> > patr...@blueri.se; mbrug...@suse.com; eugeniy.palt...@synopsys.com;
> > weijie@mediatek.com; nsaenzjulie...@suse.de;
> feste...@gmail.com;
> > sean...@gmail.com; Sagar Kadam
> > Subject: [PATCH v4 0/5] add DM based reset driver for SiFive SoC's
> >
> > The FU540-C000 support in U-Boot is missing DM based reset driver, and is
> > handling reset's to sub-system within the prci driver itself.
> > The series here adds a generic DM reset driver for SiFive SoC's so as to
> > leverage the U-Boot's reset framework and binds the reset driver with prci
> > driver.
> > The PRCI driver takes care of triggering the consumers reset signals
> > appropriately.
> >
> > Patch 1: Add necessary dt indexes for device reset register.
> > Patch 2: Update macro's to use common dt indexes from binding header.
> > Patch 3: Add reset producer and consumer entries within the device tree.
> > Patch 4: Add reset dm driver and bind it within prci module.
> > Patch 5: Add Kconfig, Makefile entries and enable the driver
> >
> > This series is re-based on mainline U-Boot commit 5d3a21df6694 ("Merge
> tag
> > 'dm-pull-20jul20' of git://git.denx.de/u-boot-dm") and depends on [1]
> >
> > [1] https://patchwork.ozlabs.org/project/uboot/list/?series=190862
> >
>
> I have rebased this series on u-boot/master.
> Can you please pull it and let me know if any issues are there.
>
It seems that u-boot/master is moved ahead and the commit on which this series
was based is reverted "Revert "Merge tag 'dm-pull-20jul20' of
git://git.denx.de/u-boot-dm""
and will again conflict considering other patch's that are merged in
u-boot/master.
I can rebase it again, but would like to know what you would prefer me to
rebase on u-boot/master
or u-boot-riscv/master?
Thanks & BR,
Sagar
> Thanks & BR,
> Sagar
>
> > History:
> > ==
> > V4:
> > -Rebased the series to u-boot/master.
> >
> > V3:
> > -Add reset indexes in separate dt binding header instead of updating the
> > clock dt binding header which is synced from Linux
> >
> > V2:
> > -Removed extra character in commit log of 2nd patch
> >
> > V1:
> > -Base version.
> >
> > Sagar Shrikant Kadam (5):
> > dt-bindings: prci: add indexes for reset signals available in prci
> > fu540: prci: use common reset indexes defined in binding header
> > fu540: dtsi: add reset producer and consumer entries
> > sifive: reset: add DM based reset driver for SiFive SoC's
> > configs: reset: fu540: enable dm reset framework for SiFive
> >
> > arch/riscv/dts/fu540-c000-u-boot.dtsi | 12 +++
> > arch/riscv/include/asm/arch-fu540/reset.h | 13 +++
> > configs/sifive_fu540_defconfig| 2 +
> > drivers/clk/sifive/fu540-prci.c | 90 ++--
> > drivers/reset/Kconfig | 9 ++
> > drivers/reset/Makefile| 1 +
> > drivers/reset/reset-sifive.c | 118
> > ++
> > include/dt-bindings/reset/sifive-fu540-prci.h | 19 +
> > 8 files changed, 239 insertions(+), 25 deletions(-) create mode 100644
> > arch/riscv/include/asm/arch-fu540/reset.h
> > create mode 100644 drivers/reset/reset-sifive.c create mode 100644
> > include/dt-bindings/reset/sifive-fu540-prci.h
> >
> > --
> > 2.7.4
RE: [PATCH v4 0/5] add DM based reset driver for SiFive SoC's
Hi Rick,
> -Original Message-
> From: Sagar Kadam
> Sent: Friday, July 24, 2020 2:17 PM
> To: u-boot@lists.denx.de
> Cc: r...@andestech.com; Paul Walmsley ( Sifive)
> ; pal...@dabbelt.com; anup.pa...@wdc.com;
> atish.pa...@wdc.com; lu...@denx.de; Pragnesh Patel
> ; bin.m...@windriver.com;
> ja...@amarulasolutions.com; s...@chromium.org; twoer...@gmail.com;
> patr...@blueri.se; mbrug...@suse.com; eugeniy.palt...@synopsys.com;
> weijie@mediatek.com; nsaenzjulie...@suse.de; feste...@gmail.com;
> sean...@gmail.com; Sagar Kadam
> Subject: [PATCH v4 0/5] add DM based reset driver for SiFive SoC's
>
> The FU540-C000 support in U-Boot is missing DM based reset driver, and is
> handling reset's to sub-system within the prci driver itself.
> The series here adds a generic DM reset driver for SiFive SoC's so as to
> leverage the U-Boot's reset framework and binds the reset driver with prci
> driver.
> The PRCI driver takes care of triggering the consumers reset signals
> appropriately.
>
> Patch 1: Add necessary dt indexes for device reset register.
> Patch 2: Update macro's to use common dt indexes from binding header.
> Patch 3: Add reset producer and consumer entries within the device tree.
> Patch 4: Add reset dm driver and bind it within prci module.
> Patch 5: Add Kconfig, Makefile entries and enable the driver
>
> This series is re-based on mainline U-Boot commit 5d3a21df6694 ("Merge tag
> 'dm-pull-20jul20' of git://git.denx.de/u-boot-dm") and depends on [1]
>
> [1] https://patchwork.ozlabs.org/project/uboot/list/?series=190862
>
I have rebased this series on u-boot/master.
Can you please pull it and let me know if any issues are there.
Thanks & BR,
Sagar
> History:
> ==
> V4:
> -Rebased the series to u-boot/master.
>
> V3:
> -Add reset indexes in separate dt binding header instead of updating the
> clock dt binding header which is synced from Linux
>
> V2:
> -Removed extra character in commit log of 2nd patch
>
> V1:
> -Base version.
>
> Sagar Shrikant Kadam (5):
> dt-bindings: prci: add indexes for reset signals available in prci
> fu540: prci: use common reset indexes defined in binding header
> fu540: dtsi: add reset producer and consumer entries
> sifive: reset: add DM based reset driver for SiFive SoC's
> configs: reset: fu540: enable dm reset framework for SiFive
>
> arch/riscv/dts/fu540-c000-u-boot.dtsi | 12 +++
> arch/riscv/include/asm/arch-fu540/reset.h | 13 +++
> configs/sifive_fu540_defconfig| 2 +
> drivers/clk/sifive/fu540-prci.c | 90 ++--
> drivers/reset/Kconfig | 9 ++
> drivers/reset/Makefile| 1 +
> drivers/reset/reset-sifive.c | 118
> ++
> include/dt-bindings/reset/sifive-fu540-prci.h | 19 +
> 8 files changed, 239 insertions(+), 25 deletions(-) create mode 100644
> arch/riscv/include/asm/arch-fu540/reset.h
> create mode 100644 drivers/reset/reset-sifive.c create mode 100644
> include/dt-bindings/reset/sifive-fu540-prci.h
>
> --
> 2.7.4
RE: [PATCH 6/6] riscv: Update SiFive device tree for new CLINT driver
> -Original Message-
> From: Sean Anderson
> Sent: Friday, July 24, 2020 1:58 AM
> To: Sagar Kadam ; Bin Meng
>
> Cc: Pragnesh Patel ; U-Boot Mailing List b...@lists.denx.de>; Rick Chen
> Subject: Re: [PATCH 6/6] riscv: Update SiFive device tree for new CLINT driver
>
> [External Email] Do not click links or attachments unless you recognize the
> sender and know the content is safe
>
> On 7/23/20 12:51 PM, Sagar Kadam wrote:
> > Hello Sean,
> >
> >> -Original Message-
> >> From: Sean Anderson
> >> Sent: Thursday, July 23, 2020 8:22 PM
> >> To: Bin Meng
> >> Cc: Pragnesh Patel ; Sagar Kadam
> >> ; U-Boot Mailing List ;
> >> Rick Chen
> >> Subject: Re: [PATCH 6/6] riscv: Update SiFive device tree for new
> >> CLINT driver
> >>
> >> [External Email] Do not click links or attachments unless you
> >> recognize the sender and know the content is safe
> >>
> >> On 7/23/20 10:47 AM, Bin Meng wrote:
> >>> Hi Sean,
> >>>
> >>> On Thu, Jul 23, 2020 at 9:57 PM Sean Anderson
> >> wrote:
> >>>>
> >>>> On 7/23/20 9:50 AM, Bin Meng wrote:
> >>>>> Hi Sean,
> >>>>>
> >>>>> On Wed, Jul 22, 2020 at 11:51 PM Sean Anderson
>
> >> wrote:
> >>>>>>
> >>>>>> We may need to add a clock-frequency binding like for the K210.
> >>>>>>
> >>>>>> Signed-off-by: Sean Anderson
> >>>>>> ---
> >>>>>> This patch builds but has NOT been tested.
> >>>>>>
> >>>>>> arch/riscv/dts/fu540-c000-u-boot.dtsi | 7 ++-
> >>>>>> 1 file changed, 6 insertions(+), 1 deletion(-)
> >>>>>>
> >>>>>> diff --git a/arch/riscv/dts/fu540-c000-u-boot.dtsi
> >>>>>> b/arch/riscv/dts/fu540-c000-u-boot.dtsi
> >>>>>> index afdb4f4402..e56bfc7595 100644
> >>>>>> --- a/arch/riscv/dts/fu540-c000-u-boot.dtsi
> >>>>>> +++ b/arch/riscv/dts/fu540-c000-u-boot.dtsi
> >>>>>> @@ -55,8 +55,13 @@
> >>>>>> };
> >>>>>> clint@200 {
> >>>>>> compatible = "riscv,clint0";
> >>>>>> - interrupts-extended = <_intc 3 _intc
> >>>>>> 7
> >> _intc 3 _intc 7 _intc 3 _intc 7 _intc 3
> >> _intc 7 _intc 3 _intc 7>;
> >>>>>> + interrupts-extended = <_intc 3 _intc
> >>>>>> 7
> >>>>>> + _intc 3 _intc
> >>>>>> 7
> >>>>>> + _intc 3 _intc
> >>>>>> 7
> >>>>>> + _intc 3 _intc
> >>>>>> 7
> >>>>>> + _intc 3
> >>>>>> + _intc 7>;
> >>>>>> reg = <0x0 0x200 0x0 0xc>;
> >>>>>> + clocks = < PRCI_CLK_COREPLL>;
> >>>>>
> >>>>> This looks wrong to me. The CLINT timer frequency should come from
> >>>>> the
> >> RTC node.
> >>>>>
> >>>>> +Pragnesh Patel
> >>>>>
> >>>>> +Sagar Kadam
> >>>>
> >>>> On further review, I think you are right that this should be
> RTCCLK_FREQ.
> >>>>
> >>>> Perhaps the clocks part should be moved into
> >>>> arch/riscv/dts/hifive-unleashed-a00-u-boot.dts and changed to
> >>>> something like
> >>>>
> >>>> clocks = <>;
> >>>
> >
> > Yes, CLINT is driven by RTC clock.
> >
> >>> How does the device tree look like in the upstream Linux to work
> >>> with the new CLINT timer driver?
> >>>
> >>> Regards,
> >>> Bin
> >>
> >> Anup's patch doesn't change the device tree at all so I think they
> >> are still using timebase-frequency.
> >>
> > In that case I was wondering what would be better:
> > 1. IMHO we can skip the property as in your patch [4/6] riscv: Rework Sifive
> CLINT as UCLASS_TIMER driver
> > has a fallback to timebase-frequency, in case clock for clint is not
> specified and is falling back to timebase-frequency
> > which is again set to RTCCLK_FREQ
> > 2. OR Shift the clock part to board -uboot dts file as you are suggesting in
> order to keep it synonymous with other TIMER
> > changes done as a part of this series.
>
> I prefer the second option for two reasons. First, properties which affect a
> device should be located near its binding in the device tree.
> Using timebase-frequency only really makes sense when the cpu itself is the
> timer device. This is the case when we read the time from a CSR, but not
> when there is a separate device. Second, it lets the device use the clock
> subsystem which adds flexibility. If the device is configured for a different
> clock speed, the timer can adjust itself.
>
Okay, agreed.
Thanks for clarification.
BR,
Sagar
> --Sean
RE: [PATCH 5/6] riscv: Update Kendryte device tree for new CLINT driver
Hi Sean/Bin, > -Original Message- > From: Sean Anderson > Sent: Thursday, July 23, 2020 7:30 PM > To: Bin Meng > Cc: Sagar Kadam ; u-boot@lists.denx.de; Rick > Chen > Subject: Re: [PATCH 5/6] riscv: Update Kendryte device tree for new CLINT > driver > > [External Email] Do not click links or attachments unless you recognize the > sender and know the content is safe > > On 7/23/20 9:49 AM, Bin Meng wrote: > > Hi Sean, > > > > On Thu, Jul 23, 2020 at 7:56 PM Sean Anderson > wrote: > >> > >> On 7/23/20 7:49 AM, Sagar Kadam wrote: > >>> Hello Sean, > >>> > >>>> -Original Message- > >>>> From: U-Boot On Behalf Of Sean > >>>> Anderson > >>>> Sent: Wednesday, July 22, 2020 9:21 PM > >>>> To: u-boot@lists.denx.de > >>>> Cc: Bin Meng ; Rick Chen > >>>> ; Sean Anderson > >>>> Subject: [PATCH 5/6] riscv: Update Kendryte device tree for new > >>>> CLINT driver > >>>> > >>>> [External Email] Do not click links or attachments unless you > >>>> recognize the sender and know the content is safe > >>>> > >>>> AFAIK because the K210 clock driver does not come up until after > >>>> relocation, the clint will always use the clock-frequency parameter. > >>>> Ideally, it should update itself after relocation to take into > >>>> account the actual CPU frequency. > >>>> > >>>> Signed-off-by: Sean Anderson > >>>> --- > >>>> > >>>> arch/riscv/dts/k210.dtsi| 10 ++ > >>>> drivers/clk/kendryte/clk.c | 4 > >>>> include/dt-bindings/clock/k210-sysctl.h | 1 + > >>> > >>> Can you please consider splitting the dt-bindings include into > >>> separate patch so as to avoid checkpatch warning. > >> > >> If you'd like. AFAIK this is mostly a kernel thing since dt-bindings > >> often have separate maintainers than the rest of the series. Can > >> anyone comment on whether this applies to U-Boot as well? > > > > If the changes are from upstream Linux kernel, it's fine to keep the > > changes in the k210.dtsi. But if the changes are only needed in > > U-Boot, as Sagar mentioned they should be in k210-uboot.dtsi. > > Here the question is whether the patch should be split, not what file the > changes should go in. At the moment, the dts is not synced between U-Boot > and Linux for the K210, so there is no need to have a separate device tree > file. > Sorry if my statement turned confusing, (I didn't mean it to be into k210-uboot.dtsi), what I meant to say is we might consider splitting the dt-bindings header change into another patch within this series. cause the checkpatch show's a warning as below: #/scripts/checkpatch.pl 0005-riscv-Update-Kendryte-device-tree-for-new-CLINT-driv.patch WARNING: DT binding docs and includes should be a separate patch. See: Documentation/devicetree/bindings/submitting-patches.txt total: 0 errors, 1 warnings, 0 checks, 49 lines checked i.e IIUC, the changes in include/dt-bindings/clock/k210-sysctl.h is expected to be as a separate patch within this series. So the split of this patch can be as -Patch 5 can be :" riscv: Update Kendryte device tree for new CLINT driver" arch/riscv/dts/k210.dtsi| 10 ++ drivers/clk/kendryte/clk.c | 4 -Patch 6 can be something like: "dt-bindings: clk: k210: add clint clock identifier" include/dt-bindings/clock/k210-sysctl.h | 1 + Thanks & BR, Sagar > --Sean
RE: [PATCH 6/6] riscv: Update SiFive device tree for new CLINT driver
Hello Sean,
> -Original Message-
> From: Sean Anderson
> Sent: Thursday, July 23, 2020 8:22 PM
> To: Bin Meng
> Cc: Pragnesh Patel ; Sagar Kadam
> ; U-Boot Mailing List ; Rick
> Chen
> Subject: Re: [PATCH 6/6] riscv: Update SiFive device tree for new CLINT driver
>
> [External Email] Do not click links or attachments unless you recognize the
> sender and know the content is safe
>
> On 7/23/20 10:47 AM, Bin Meng wrote:
> > Hi Sean,
> >
> > On Thu, Jul 23, 2020 at 9:57 PM Sean Anderson
> wrote:
> >>
> >> On 7/23/20 9:50 AM, Bin Meng wrote:
> >>> Hi Sean,
> >>>
> >>> On Wed, Jul 22, 2020 at 11:51 PM Sean Anderson
> wrote:
> >>>>
> >>>> We may need to add a clock-frequency binding like for the K210.
> >>>>
> >>>> Signed-off-by: Sean Anderson
> >>>> ---
> >>>> This patch builds but has NOT been tested.
> >>>>
> >>>> arch/riscv/dts/fu540-c000-u-boot.dtsi | 7 ++-
> >>>> 1 file changed, 6 insertions(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/arch/riscv/dts/fu540-c000-u-boot.dtsi
> >>>> b/arch/riscv/dts/fu540-c000-u-boot.dtsi
> >>>> index afdb4f4402..e56bfc7595 100644
> >>>> --- a/arch/riscv/dts/fu540-c000-u-boot.dtsi
> >>>> +++ b/arch/riscv/dts/fu540-c000-u-boot.dtsi
> >>>> @@ -55,8 +55,13 @@
> >>>> };
> >>>> clint@200 {
> >>>> compatible = "riscv,clint0";
> >>>> - interrupts-extended = <_intc 3 _intc 7
> _intc 3 _intc 7 _intc 3 _intc 7 _intc 3
> _intc 7 _intc 3 _intc 7>;
> >>>> + interrupts-extended = <_intc 3 _intc 7
> >>>> + _intc 3 _intc 7
> >>>> + _intc 3 _intc 7
> >>>> + _intc 3 _intc 7
> >>>> + _intc 3
> >>>> + _intc 7>;
> >>>> reg = <0x0 0x200 0x0 0xc>;
> >>>> + clocks = < PRCI_CLK_COREPLL>;
> >>>
> >>> This looks wrong to me. The CLINT timer frequency should come from the
> RTC node.
> >>>
> >>> +Pragnesh Patel
> >>>
> >>> +Sagar Kadam
> >>
> >> On further review, I think you are right that this should be RTCCLK_FREQ.
> >>
> >> Perhaps the clocks part should be moved into
> >> arch/riscv/dts/hifive-unleashed-a00-u-boot.dts and changed to
> >> something like
> >>
> >> clocks = <>;
> >
Yes, CLINT is driven by RTC clock.
> > How does the device tree look like in the upstream Linux to work with
> > the new CLINT timer driver?
> >
> > Regards,
> > Bin
>
> Anup's patch doesn't change the device tree at all so I think they are still
> using
> timebase-frequency.
>
In that case I was wondering what would be better:
1. IMHO we can skip the property as in your patch [4/6] riscv: Rework Sifive
CLINT as UCLASS_TIMER driver
has a fallback to timebase-frequency, in case clock for clint is not
specified and is falling back to timebase-frequency
which is again set to RTCCLK_FREQ
2. OR Shift the clock part to board -uboot dts file as you are suggesting in
order to keep it synonymous with other TIMER
changes done as a part of this series.
Thanks & BR,
Sagar
> --Sean
RE: [PATCH 5/6] riscv: Update Kendryte device tree for new CLINT driver
Hello Sean,
> -Original Message-
> From: U-Boot On Behalf Of Sean Anderson
> Sent: Wednesday, July 22, 2020 9:21 PM
> To: u-boot@lists.denx.de
> Cc: Bin Meng ; Rick Chen ;
> Sean Anderson
> Subject: [PATCH 5/6] riscv: Update Kendryte device tree for new CLINT driver
>
> [External Email] Do not click links or attachments unless you recognize the
> sender and know the content is safe
>
> AFAIK because the K210 clock driver does not come up until after
> relocation, the clint will always use the clock-frequency parameter.
> Ideally, it should update itself after relocation to take into account the
> actual CPU frequency.
>
> Signed-off-by: Sean Anderson
> ---
>
> arch/riscv/dts/k210.dtsi| 10 ++
> drivers/clk/kendryte/clk.c | 4
> include/dt-bindings/clock/k210-sysctl.h | 1 +
Can you please consider splitting the dt-bindings include into separate patch
so as to avoid checkpatch warning.
Thanks & BR,
Sagar
> 3 files changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/arch/riscv/dts/k210.dtsi b/arch/riscv/dts/k210.dtsi
> index 2546c7d4e0..9583694c46 100644
> --- a/arch/riscv/dts/k210.dtsi
> +++ b/arch/riscv/dts/k210.dtsi
> @@ -17,6 +17,8 @@
> compatible = "kendryte,k210";
>
> aliases {
> + cpu0 =
> + cpu1 =
> dma0 =
> gpio0 =
> gpio1 = _0;
> @@ -40,7 +42,6 @@
> cpus {
> #address-cells = <1>;
> #size-cells = <0>;
> - timebase-frequency = <780>;
> cpu0: cpu@0 {
> device_type = "cpu";
> compatible = "kendryte,k210", "sifive,rocket0",
> "riscv";
> @@ -126,14 +127,15 @@
> read-only;
> };
>
> - clint0: interrupt-controller@200 {
> + clint0: clint@200 {
> #interrupt-cells = <1>;
> compatible = "kendryte,k210-clint", "riscv,clint0";
> reg = <0x200 0xC000>;
> - interrupt-controller;
> interrupts-extended = <_intc 3>, <_intc 7>,
> <_intc 3>, <_intc 7>;
> - clocks = < K210_CLK_CPU>;
> + clocks = < K210_CLK_CLINT>;
> + /* sysclk is only available post-relocation */
> + clock-frequency = <780>;
> };
>
> plic0: interrupt-controller@C00 {
> diff --git a/drivers/clk/kendryte/clk.c b/drivers/clk/kendryte/clk.c
> index 981b3b7699..bb196961af 100644
> --- a/drivers/clk/kendryte/clk.c
> +++ b/drivers/clk/kendryte/clk.c
> @@ -646,6 +646,10 @@ static int k210_clk_probe(struct udevice *dev)
> REGISTER_GATE(K210_CLK_RTC, "rtc", in0);
> #undef REGISTER_GATE
>
> + /* The MTIME register in CLINT runs at one 50th the CPU clock speed */
> + clk_dm(K210_CLK_CLINT,
> + clk_register_fixed_factor(NULL, "clint", "cpu", 0, 1, 50));
> +
> return 0;
> }
>
> diff --git a/include/dt-bindings/clock/k210-sysctl.h b/include/dt-
> bindings/clock/k210-sysctl.h
> index 0e3ed3fb9f..fe852bbd92 100644
> --- a/include/dt-bindings/clock/k210-sysctl.h
> +++ b/include/dt-bindings/clock/k210-sysctl.h
> @@ -55,5 +55,6 @@
> #define K210_CLK_OTP43
> #define K210_CLK_RTC44
> #define K210_CLK_ACLK 45
> +#define K210_CLK_CLINT 46
>
> #endif /* CLOCK_K210_SYSCTL_H */
> --
> 2.27.0
RE: [PATCH v3 5/5] configs: reset: fu540: enable dm reset framework for SiFive SoC
Hi Rick, > -Original Message- > From: Rick Chen > Sent: Thursday, July 23, 2020 7:56 AM > To: Sagar Kadam > Cc: U-Boot Mailing List ; Paul Walmsley ( Sifive) > ; Palmer Dabbelt ; Anup > Patel ; Atish Patra ; Lukasz > Majewski ; Pragnesh Patel ; Bin > Meng ; Jagan Teki ; > Simon Glass ; Trevor Woerner ; > rick ; Alan Kao > Subject: Re: [PATCH v3 5/5] configs: reset: fu540: enable dm reset framework > for SiFive SoC > > [External Email] Do not click links or attachments unless you recognize the > sender and know the content is safe > > Hi Sagar > > > From: Sagar Shrikant Kadam [mailto:sagar.ka...@sifive.com] > > Sent: Friday, July 10, 2020 4:38 PM > > To: u-boot@lists.denx.de > > Cc: Rick Jian-Zhi Chen(陳建志); paul.walms...@sifive.com; > > pal...@dabbelt.com; anup.pa...@wdc.com; atish.pa...@wdc.com; > > lu...@denx.de; pragnesh.pa...@sifive.com; bin.m...@windriver.com; > > ja...@amarulasolutions.com; s...@chromium.org; twoer...@gmail.com; > > abrod...@synopsys.com; eugeniy.palt...@synopsys.com; > > patr...@blueri.se; weijie@mediatek.com; feste...@gmail.com; Sagar > > Shrikant Kadam > > Subject: [PATCH v3 5/5] configs: reset: fu540: enable dm reset > > framework for SiFive SoC > > > > Add necessary defconfig and Kconfig entries to enable SiFive SoC's reset > driver so as to utilise U-Boot's reset framework. > > > > Signed-off-by: Sagar Shrikant Kadam > > Reviewed-by: Pragnesh Patel > > Reviewed-by: Bin Meng > > Tested-by: Bin Meng > > --- > > configs/sifive_fu540_defconfig | 2 ++ > > drivers/reset/Kconfig | 9 + > > drivers/reset/Makefile | 1 + > > 3 files changed, 12 insertions(+) > > > > diff --git a/configs/sifive_fu540_defconfig > > b/configs/sifive_fu540_defconfig index 32347c2..12f2469 100644 > > --- a/configs/sifive_fu540_defconfig > > +++ b/configs/sifive_fu540_defconfig > > @@ -20,3 +20,5 @@ CONFIG_DEFAULT_DEVICE_TREE="hifive-unleashed- > a00" > > CONFIG_SYS_RELOC_GD_ENV_ADDR=y > > CONFIG_SPL_CLK=y > > CONFIG_DM_MTD=y > > +CONFIG_SPL_DM_RESET=y > > +CONFIG_DM_RESET=y > > diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig index > > 88d3be1..627f8e8 100644 > > --- a/drivers/reset/Kconfig > > +++ b/drivers/reset/Kconfig > > @@ -148,4 +148,13 @@ config RESET_IMX7 > > help > > Support for reset controller on i.MX7/8 SoCs. > > > > +config RESET_SIFIVE > > + bool "Reset Driver for SiFive SoC's" > > + depends on DM_RESET && CLK_SIFIVE_FU540_PRCI && > TARGET_SIFIVE_FU540 > > + default y > > + help > > + PRCI module within SiFive SoC's provides mechanism to reset > > + different hw blocks like DDR, gemgxl. With this driver we leverage > > + U-Boot's reset framework to reset these hardware blocks. > > + > > endmenu > > diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile index > > 0a044d5..e3c27c4 100644 > > --- a/drivers/reset/Makefile > > +++ b/drivers/reset/Makefile > > @@ -23,3 +23,4 @@ obj-$(CONFIG_RESET_MTMIPS) += reset-mtmips.o > > obj-$(CONFIG_RESET_SUNXI) += reset-sunxi.o > > obj-$(CONFIG_RESET_HISILICON) += reset-hisilicon.o > > obj-$(CONFIG_RESET_IMX7) += reset-imx7.o > > +obj-$(CONFIG_RESET_SIFIVE) += reset-sifive.o > > This patch conflicts with u-boot/master, please rebase. > Ok, I will rebase the series on u-boot/master and send it. Thanks & BR, Sagar > Applying: dt-bindings: prci: add indexes for reset signals available in prci > Applying: fu540: prci: use common reset indexes defined in binding header > Applying: fu540: dtsi: add reset producer and consumer entries > Applying: sifive: reset: add DM based reset driver for SiFive SoC's > Applying: configs: reset: fu540: enable dm reset framework for SiFive SoC > error: patch failed: drivers/reset/Kconfig:148 > error: drivers/reset/Kconfig: patch does not apply > error: patch failed: drivers/reset/Makefile:23 > error: drivers/reset/Makefile: patch does not apply Patch failed at 0005 > configs: > reset: fu540: enable dm reset framework for SiFive SoC > > Thanks, > Rick
RE: [PATCH v2 1/5] dt-bindings: prci: add indexes for reset signals available in prci
Hi Jagan, A gentle reminder here. > -Original Message- > From: U-Boot On Behalf Of Sagar Kadam > Sent: Friday, July 3, 2020 12:25 PM > To: Jagan Teki > Cc: U-Boot-Denx ; Rick Chen ; > Paul Walmsley ( Sifive) ; Palmer Dabbelt > ; Anup Patel ; Atish Patra > ; Lukasz Majewski ; Pragnesh > Patel ; bin.m...@windriver.com; Simon Glass > ; Trevor Woerner ; Eugeniy > Paltsev ; Patrick Wildt > ; Weijie Gao ; Fabio > Estevam > Subject: RE: [PATCH v2 1/5] dt-bindings: prci: add indexes for reset signals > available in prci > > Hi Jagan, > > > -Original Message- > > From: Jagan Teki > > Sent: Friday, July 3, 2020 12:04 PM > > To: Sagar Kadam > > Cc: U-Boot-Denx ; Rick Chen > ; > > Paul Walmsley ( Sifive) ; Palmer Dabbelt > > ; Anup Patel ; Atish Patra > > ; Lukasz Majewski ; Pragnesh > > Patel ; bin.m...@windriver.com; Simon > Glass > > ; Trevor Woerner ; Eugeniy > > Paltsev ; Patrick Wildt > > ; Weijie Gao ; Fabio > > Estevam > > Subject: Re: [PATCH v2 1/5] dt-bindings: prci: add indexes for reset signals > > available in prci > > > > [External Email] Do not click links or attachments unless you recognize the > > sender and know the content is safe > > > > On Fri, Jul 3, 2020 at 11:52 AM Sagar Kadam > > wrote: > > > > > > > > > > -Original Message- > > > > From: U-Boot On Behalf Of Sagar > > Kadam > > > > Sent: Monday, June 29, 2020 9:37 PM > > > > To: Jagan Teki > > > > Cc: U-Boot-Denx ; Rick Chen > > > > ; Paul Walmsley ( Sifive) > > > > ; Palmer Dabbelt ; > > > > Anup Patel ; Atish Patra > > ; > > > > Lukasz Majewski ; Pragnesh Patel > > > > ; bin.m...@windriver.com; Simon Glass > > > > ; Trevor Woerner ; > Eugeniy > > > > Paltsev ; Patrick Wildt > > > > ; Weijie Gao ; Fabio > > > > Estevam > > > > Subject: RE: [PATCH v2 1/5] dt-bindings: prci: add indexes for reset > > > > signals available in prci > > > > > > > > Hello Jagan, > > > > > -Original Message- > > > > > From: Jagan Teki > > > > > Sent: Monday, June 29, 2020 9:00 PM > > > > > To: Sagar Kadam > > > > > Cc: U-Boot-Denx ; Rick Chen > > > > > ; Paul Walmsley ( Sifive) > > > > > ; Palmer Dabbelt > ; > > > > Anup > > > > > Patel ; Atish Patra ; > > > > > Lukasz Majewski ; Pragnesh Patel > > > > ; > > > > > bin.m...@windriver.com; Simon Glass ; Trevor > > > > Woerner > > > > > ; Eugeniy Paltsev > > > > ; > > > > > Patrick Wildt ; Weijie Gao > > > > > ; Fabio Estevam > > > > > Subject: Re: [PATCH v2 1/5] dt-bindings: prci: add indexes for > > > > > reset signals available in prci > > > > > > > > > > [External Email] Do not click links or attachments unless you > > > > > recognize the sender and know the content is safe > > > > > > > > > > On Fri, Jun 26, 2020 at 8:51 AM Sagar Kadam > > > > > > > > > > wrote: > > > > > > > > > > > > Hi Jagan, > > > > > > > > > > > > > -Original Message- > > > > > > > From: Jagan Teki > > > > > > > Sent: Thursday, June 25, 2020 11:13 PM > > > > > > > To: Sagar Kadam > > > > > > > Cc: U-Boot-Denx ; Rick Chen > > > > > ; > > > > > > > Paul Walmsley ( Sifive) ; Palmer > > > > > > > Dabbelt ; Anup Patel > > ; > > > > > > > Atish > > > > > Patra > > > > > > > ; Lukasz Majewski ; > > > > Pragnesh > > > > > > > Patel ; bin.m...@windriver.com; > > > > > > > Simon > > > > > Glass > > > > > > > ; Trevor Woerner ; > > > > Eugeniy > > > > > > > Paltsev ; Patrick Wildt > > > > > > > ; Weijie Gao ; > > > > > > > Fabio Estevam > > > > > > > Subject: Re: [PATCH v2 1/5] dt-bindings: prci: add indexes for > > > > > > > reset > > > > > signals > > > > > > > available in prci > > > > > > > > > > > > > > [External Email]
RE: [PATCH v2 1/5] dt-bindings: prci: add indexes for reset signals available in prci
Hi Jagan, > -Original Message- > From: Jagan Teki > Sent: Friday, July 3, 2020 12:04 PM > To: Sagar Kadam > Cc: U-Boot-Denx ; Rick Chen ; > Paul Walmsley ( Sifive) ; Palmer Dabbelt > ; Anup Patel ; Atish Patra > ; Lukasz Majewski ; Pragnesh > Patel ; bin.m...@windriver.com; Simon Glass > ; Trevor Woerner ; Eugeniy > Paltsev ; Patrick Wildt > ; Weijie Gao ; Fabio > Estevam > Subject: Re: [PATCH v2 1/5] dt-bindings: prci: add indexes for reset signals > available in prci > > [External Email] Do not click links or attachments unless you recognize the > sender and know the content is safe > > On Fri, Jul 3, 2020 at 11:52 AM Sagar Kadam > wrote: > > > > > > > -Original Message- > > > From: U-Boot On Behalf Of Sagar > Kadam > > > Sent: Monday, June 29, 2020 9:37 PM > > > To: Jagan Teki > > > Cc: U-Boot-Denx ; Rick Chen > > > ; Paul Walmsley ( Sifive) > > > ; Palmer Dabbelt ; > > > Anup Patel ; Atish Patra > ; > > > Lukasz Majewski ; Pragnesh Patel > > > ; bin.m...@windriver.com; Simon Glass > > > ; Trevor Woerner ; Eugeniy > > > Paltsev ; Patrick Wildt > > > ; Weijie Gao ; Fabio > > > Estevam > > > Subject: RE: [PATCH v2 1/5] dt-bindings: prci: add indexes for reset > > > signals available in prci > > > > > > Hello Jagan, > > > > -Original Message- > > > > From: Jagan Teki > > > > Sent: Monday, June 29, 2020 9:00 PM > > > > To: Sagar Kadam > > > > Cc: U-Boot-Denx ; Rick Chen > > > > ; Paul Walmsley ( Sifive) > > > > ; Palmer Dabbelt ; > > > Anup > > > > Patel ; Atish Patra ; > > > > Lukasz Majewski ; Pragnesh Patel > > > ; > > > > bin.m...@windriver.com; Simon Glass ; Trevor > > > Woerner > > > > ; Eugeniy Paltsev > > > ; > > > > Patrick Wildt ; Weijie Gao > > > > ; Fabio Estevam > > > > Subject: Re: [PATCH v2 1/5] dt-bindings: prci: add indexes for > > > > reset signals available in prci > > > > > > > > [External Email] Do not click links or attachments unless you > > > > recognize the sender and know the content is safe > > > > > > > > On Fri, Jun 26, 2020 at 8:51 AM Sagar Kadam > > > > > > > > wrote: > > > > > > > > > > Hi Jagan, > > > > > > > > > > > -Original Message- > > > > > > From: Jagan Teki > > > > > > Sent: Thursday, June 25, 2020 11:13 PM > > > > > > To: Sagar Kadam > > > > > > Cc: U-Boot-Denx ; Rick Chen > > > > ; > > > > > > Paul Walmsley ( Sifive) ; Palmer > > > > > > Dabbelt ; Anup Patel > ; > > > > > > Atish > > > > Patra > > > > > > ; Lukasz Majewski ; > > > Pragnesh > > > > > > Patel ; bin.m...@windriver.com; > > > > > > Simon > > > > Glass > > > > > > ; Trevor Woerner ; > > > Eugeniy > > > > > > Paltsev ; Patrick Wildt > > > > > > ; Weijie Gao ; > > > > > > Fabio Estevam > > > > > > Subject: Re: [PATCH v2 1/5] dt-bindings: prci: add indexes for > > > > > > reset > > > > signals > > > > > > available in prci > > > > > > > > > > > > [External Email] Do not click links or attachments unless you > > > > > > recognize > > > > the > > > > > > sender and know the content is safe > > > > > > > > > > > > On Thu, Jun 25, 2020 at 5:56 PM Sagar Shrikant Kadam > > > > > > wrote: > > > > > > > > > > > > > > Add bit indexes for reset signals within the PRCI module on > > > > > > > FU540-C000 SoC. > > > > > > > The DDR and ethernet sub-system's have reset signals > > > > > > > indicated by these reset indexes. > > > > > > > > > > > > > > Signed-off-by: Sagar Shrikant Kadam > > > > > > > Reviewed-by: Pragnesh Patel > > > > > > > Reviewed-by: Bin Meng > > > > > > > --- > > > > > > > include/dt-bindings/clock/sifive-fu540-prci.h | 8 > > > > > > > 1 file changed, 8 insertions(+) > > > >
RE: [PATCH v2 1/5] dt-bindings: prci: add indexes for reset signals available in prci
> -Original Message- > From: U-Boot On Behalf Of Sagar Kadam > Sent: Monday, June 29, 2020 9:37 PM > To: Jagan Teki > Cc: U-Boot-Denx ; Rick Chen ; > Paul Walmsley ( Sifive) ; Palmer Dabbelt > ; Anup Patel ; Atish Patra > ; Lukasz Majewski ; Pragnesh > Patel ; bin.m...@windriver.com; Simon Glass > ; Trevor Woerner ; Eugeniy > Paltsev ; Patrick Wildt > ; Weijie Gao ; Fabio > Estevam > Subject: RE: [PATCH v2 1/5] dt-bindings: prci: add indexes for reset signals > available in prci > > Hello Jagan, > > -Original Message- > > From: Jagan Teki > > Sent: Monday, June 29, 2020 9:00 PM > > To: Sagar Kadam > > Cc: U-Boot-Denx ; Rick Chen > > ; Paul Walmsley ( Sifive) > > ; Palmer Dabbelt ; > Anup > > Patel ; Atish Patra ; Lukasz > > Majewski ; Pragnesh Patel > ; > > bin.m...@windriver.com; Simon Glass ; Trevor > Woerner > > ; Eugeniy Paltsev > ; > > Patrick Wildt ; Weijie Gao > > ; Fabio Estevam > > Subject: Re: [PATCH v2 1/5] dt-bindings: prci: add indexes for reset > > signals available in prci > > > > [External Email] Do not click links or attachments unless you > > recognize the sender and know the content is safe > > > > On Fri, Jun 26, 2020 at 8:51 AM Sagar Kadam > > wrote: > > > > > > Hi Jagan, > > > > > > > -Original Message- > > > > From: Jagan Teki > > > > Sent: Thursday, June 25, 2020 11:13 PM > > > > To: Sagar Kadam > > > > Cc: U-Boot-Denx ; Rick Chen > > ; > > > > Paul Walmsley ( Sifive) ; Palmer Dabbelt > > > > ; Anup Patel ; Atish > > Patra > > > > ; Lukasz Majewski ; > Pragnesh > > > > Patel ; bin.m...@windriver.com; Simon > > Glass > > > > ; Trevor Woerner ; > Eugeniy > > > > Paltsev ; Patrick Wildt > > > > ; Weijie Gao ; Fabio > > > > Estevam > > > > Subject: Re: [PATCH v2 1/5] dt-bindings: prci: add indexes for > > > > reset > > signals > > > > available in prci > > > > > > > > [External Email] Do not click links or attachments unless you > > > > recognize > > the > > > > sender and know the content is safe > > > > > > > > On Thu, Jun 25, 2020 at 5:56 PM Sagar Shrikant Kadam > > > > wrote: > > > > > > > > > > Add bit indexes for reset signals within the PRCI module on > > > > > FU540-C000 SoC. > > > > > The DDR and ethernet sub-system's have reset signals indicated > > > > > by these reset indexes. > > > > > > > > > > Signed-off-by: Sagar Shrikant Kadam > > > > > Reviewed-by: Pragnesh Patel > > > > > Reviewed-by: Bin Meng > > > > > --- > > > > > include/dt-bindings/clock/sifive-fu540-prci.h | 8 > > > > > 1 file changed, 8 insertions(+) > > > > > > > > > > diff --git a/include/dt-bindings/clock/sifive-fu540-prci.h > > > > > b/include/dt- > > > > bindings/clock/sifive-fu540-prci.h > > > > > index 6a0b70a..1c03b09 100644 > > > > > --- a/include/dt-bindings/clock/sifive-fu540-prci.h > > > > > +++ b/include/dt-bindings/clock/sifive-fu540-prci.h > > > > > @@ -15,4 +15,12 @@ > > > > > #define PRCI_CLK_GEMGXLPLL2 > > > > > #define PRCI_CLK_TLCLK3 > > > > > > > > > > +/* Reset bit indexes to be used by driver */ > > > > > +#define PRCI_RST_DDR_CTRL_N0 > > > > > +#define PRCI_RST_DDR_AXI_N 1 > > > > > +#define PRCI_RST_DDR_AHB_N 2 > > > > > +#define PRCI_RST_DDR_PHY_N 3 > > > > > +/* bit 4 is reserved bit */ > > > > > +#define PRCI_RST_RSVD_N 4 > > > > > +#define PRCI_RST_GEMGXL_N 5 > > > > > #endif > > > > > > > > Do these bindings are synced from Linux? If Yes better to sync > > > > with a particular commit or tag rather than patch. > > > > > > > > > > No, these reset bindings are not synced from Linux. > > > > This is synced file from Linux, better to inline with Linux files > > always, if these bindings are not related to Linux then maintain it in > > a separate file or support it in Linux first if they do require for > > Linux. > > > Ohh. Sorry I thought you were asking if reset-bindings are from Linux. > Yes this file is synced from Linux but these reset-bindings are not related to > Linux. So I can split it and place reset bindings into another file: > "include/dt-bindings/reset/sifive-fu540-reset.h" It will be "include/dt-bindings/reset/sifive-fu540-prci.h" BR, Sagar > and include it wherever required. Please let me know if this sounds okay. > > Thanks & BR, > Sagar Kadam > > > Jagan.
RE: [PATCH v2 1/5] dt-bindings: prci: add indexes for reset signals available in prci
Hello Jagan, > -Original Message- > From: Jagan Teki > Sent: Monday, June 29, 2020 9:00 PM > To: Sagar Kadam > Cc: U-Boot-Denx ; Rick Chen ; > Paul Walmsley ( Sifive) ; Palmer Dabbelt > ; Anup Patel ; Atish Patra > ; Lukasz Majewski ; Pragnesh > Patel ; bin.m...@windriver.com; Simon Glass > ; Trevor Woerner ; Eugeniy > Paltsev ; Patrick Wildt > ; Weijie Gao ; Fabio > Estevam > Subject: Re: [PATCH v2 1/5] dt-bindings: prci: add indexes for reset signals > available in prci > > [External Email] Do not click links or attachments unless you recognize the > sender and know the content is safe > > On Fri, Jun 26, 2020 at 8:51 AM Sagar Kadam > wrote: > > > > Hi Jagan, > > > > > -Original Message- > > > From: Jagan Teki > > > Sent: Thursday, June 25, 2020 11:13 PM > > > To: Sagar Kadam > > > Cc: U-Boot-Denx ; Rick Chen > ; > > > Paul Walmsley ( Sifive) ; Palmer Dabbelt > > > ; Anup Patel ; Atish > Patra > > > ; Lukasz Majewski ; Pragnesh > > > Patel ; bin.m...@windriver.com; Simon > Glass > > > ; Trevor Woerner ; Eugeniy > > > Paltsev ; Patrick Wildt > > > ; Weijie Gao ; Fabio > > > Estevam > > > Subject: Re: [PATCH v2 1/5] dt-bindings: prci: add indexes for reset > signals > > > available in prci > > > > > > [External Email] Do not click links or attachments unless you recognize > the > > > sender and know the content is safe > > > > > > On Thu, Jun 25, 2020 at 5:56 PM Sagar Shrikant Kadam > > > wrote: > > > > > > > > Add bit indexes for reset signals within the PRCI module > > > > on FU540-C000 SoC. > > > > The DDR and ethernet sub-system's have reset signals > > > > indicated by these reset indexes. > > > > > > > > Signed-off-by: Sagar Shrikant Kadam > > > > Reviewed-by: Pragnesh Patel > > > > Reviewed-by: Bin Meng > > > > --- > > > > include/dt-bindings/clock/sifive-fu540-prci.h | 8 > > > > 1 file changed, 8 insertions(+) > > > > > > > > diff --git a/include/dt-bindings/clock/sifive-fu540-prci.h b/include/dt- > > > bindings/clock/sifive-fu540-prci.h > > > > index 6a0b70a..1c03b09 100644 > > > > --- a/include/dt-bindings/clock/sifive-fu540-prci.h > > > > +++ b/include/dt-bindings/clock/sifive-fu540-prci.h > > > > @@ -15,4 +15,12 @@ > > > > #define PRCI_CLK_GEMGXLPLL2 > > > > #define PRCI_CLK_TLCLK3 > > > > > > > > +/* Reset bit indexes to be used by driver */ > > > > +#define PRCI_RST_DDR_CTRL_N0 > > > > +#define PRCI_RST_DDR_AXI_N 1 > > > > +#define PRCI_RST_DDR_AHB_N 2 > > > > +#define PRCI_RST_DDR_PHY_N 3 > > > > +/* bit 4 is reserved bit */ > > > > +#define PRCI_RST_RSVD_N4 > > > > +#define PRCI_RST_GEMGXL_N 5 > > > > #endif > > > > > > Do these bindings are synced from Linux? If Yes better to sync with a > > > particular commit or tag rather than patch. > > > > > > > No, these reset bindings are not synced from Linux. > > This is synced file from Linux, better to inline with Linux files > always, if these bindings are not related to Linux then maintain it in > a separate file or support it in Linux first if they do require for > Linux. > Ohh. Sorry I thought you were asking if reset-bindings are from Linux. Yes this file is synced from Linux but these reset-bindings are not related to Linux. So I can split it and place reset bindings into another file: "include/dt-bindings/reset/sifive-fu540-reset.h" and include it wherever required. Please let me know if this sounds okay. Thanks & BR, Sagar Kadam > Jagan.
RE: [PATCH v6 2/4] uclass: cpu: fix to display proper CPU features
Hi Bin,
> -Original Message-
> From: Bin Meng
> Sent: Friday, June 26, 2020 6:50 PM
> To: Sagar Kadam
> Cc: U-Boot Mailing List ; Rick Chen
> ; Bin Meng ; Jagan Teki
> ; Pragnesh Patel
> ; Anup Patel ; Simon
> Glass ; Ye Li ; Peng Fan
> ; Sean Anderson
> Subject: Re: [PATCH v6 2/4] uclass: cpu: fix to display proper CPU features
>
> [External Email] Do not click links or attachments unless you recognize the
> sender and know the content is safe
>
> Hi Sagar,
>
> On Fri, Jun 26, 2020 at 8:40 PM Sagar Shrikant Kadam
> wrote:
> >
> > The cmd "cpu detail" fetches uninitialized cpu feature information and
> > thus displays wrong / inconsitent details as below.
> > For eg: FU540-C000 doesn't have any microcode, yet the cmd display's it.
> >
> > => cpu detail
> > 1: cpu@1 rv64imafdc
> > ID = 1, freq = 999.100 MHz: L1 cache, MMU, Microcode, Device ID
> > Microcode version 0x0
> > Device ID 0x0
> > 2: cpu@2 rv64imafdc
> > ID = 2, freq = 999.100 MHz: L1 cache, MMU, Microcode, Device ID
> > Microcode version 0x0
> > Device ID 0x0
> > 3: cpu@3 rv64imafdc
> > ID = 3, freq = 999.100 MHz: L1 cache, MMU, Microcode, Device ID
> > Microcode version 0x0
> > Device ID 0x0
> > 4: cpu@4 rv64imafdc
> > ID = 4, freq = 999.100 MHz: L1 cache, MMU, Microcode, Device ID
> > Microcode version 0x0
> > Device ID 0x0
> >
> > The L1 cache or MMU entry seen above is also displayed inconsistently.
> > So initialize cpu information to zero into cpu-uclass itself so that
> > similar issues can be avoided for other CPU drivers.
> >
> > We now see correct features as:
> > => cpu detail
> > 1: cpu@1 rv64imafdc
> > ID = 1, freq = 999.100 MHz
> > 2: cpu@2 rv64imafdc
> > ID = 2, freq = 999.100 MHz
> > 3: cpu@3 rv64imafdc
> > ID = 3, freq = 999.100 MHz
> > 4: cpu@4 rv64imafdc
> > ID = 4, freq = 999.100 MHz
> >
> > Signed-off-by: Sagar Shrikant Kadam
> > Reviewed-by: Pragnesh Patel
> > ---
> > drivers/cpu/cpu-uclass.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/cpu/cpu-uclass.c b/drivers/cpu/cpu-uclass.c index
> > 7418c26..9f4a8fd 100644
> > --- a/drivers/cpu/cpu-uclass.c
> > +++ b/drivers/cpu/cpu-uclass.c
> > @@ -83,6 +83,9 @@ int cpu_get_info(struct udevice *dev, struct
> > cpu_info *info) {
> > struct cpu_ops *ops = cpu_get_ops(dev);
> >
> > + /* Init cpu_info to 0 */
> > + memset(info, 0, sizeof(struct cpu_info));
> > +
>
> nits: this should be put after the if() test logic below
>
Ok. I will submit it
> > if (!ops->get_info)
> > return -ENOSYS;
> >
> > --
>
> Other than that,
> Reviewed-by: Bin Meng
>
Thanks here.
BR,
Sagar
> Regards,
> Bin
RE: [PATCH v6 3/4] riscv: cpu: correctly handle the setting of CPU_FEAT_MMU bit
Hi, > -Original Message- > From: Bin Meng > Sent: Friday, June 26, 2020 6:50 PM > To: Sagar Kadam > Cc: U-Boot Mailing List ; Rick Chen > ; Bin Meng ; Jagan Teki > ; Pragnesh Patel > ; Anup Patel ; Simon > Glass ; Ye Li ; Peng Fan > ; Sean Anderson > Subject: Re: [PATCH v6 3/4] riscv: cpu: correctly handle the setting of > CPU_FEAT_MMU bit > > [External Email] Do not click links or attachments unless you recognize the > sender and know the content is safe > > On Fri, Jun 26, 2020 at 8:41 PM Sagar Shrikant Kadam > wrote: > > > > The conditional check to read "mmu-type" from the device tree > > is not rightly handled due to which the cpu feature doesn't include > > CPU_FEAT_MMU even if it's corresponding entry is present in the device > > tree. > > > > The initialization of cpu features is now taken care in cpu-uclass > > driver, so no need to zero out cpu_freq in riscv_cpu driver and can be > > removed. > > > > Signed-off-by: Sagar Shrikant Kadam > > Reviewed-by: Pragnesh Patel > > --- > > drivers/cpu/riscv_cpu.c | 5 + > > 1 file changed, 1 insertion(+), 4 deletions(-) > > > > Reviewed-by: Bin Meng Thanks Bin. BR, Sagar
RE: [PATCH v5 3/3] riscv: cpu: check and append L1 cache to cpu features
Hi Bin, > -Original Message- > From: Bin Meng > Sent: Friday, June 26, 2020 5:51 PM > To: Sagar Kadam ; U-Boot Mailing List b...@lists.denx.de> > Cc: Rick Chen ; Jagan Teki > ; Pragnesh Patel > ; Anup Patel ; Simon > Glass ; Ye Li ; Peng Fan > ; Sean Anderson > Subject: Re: [PATCH v5 3/3] riscv: cpu: check and append L1 cache to cpu > features > > [External Email] Do not click links or attachments unless you recognize the > sender and know the content is safe > > Hi Sagar, > > On Thu, Jun 25, 2020 at 7:11 PM Bin Meng wrote: > > > > On Thu, Jun 25, 2020 at 4:12 PM Sagar Shrikant Kadam > > wrote: > > > > > > All cpu cores within FU540-C000 having split I/D caches. > > > Set the L1 cache feature bit using the i-cache-size or d-cache-size > > > as one of the property from device tree indicating that L1 cache is > > > present on the cpu core. > > > > > > => cpu detail > > > 1: cpu@1 rv64imafdc > > > ID = 1, freq = 999.100 MHz: L1 cache, MMU > > > 2: cpu@2 rv64imafdc > > > ID = 2, freq = 999.100 MHz: L1 cache, MMU > > > 3: cpu@3 rv64imafdc > > > ID = 3, freq = 999.100 MHz: L1 cache, MMU > > > 4: cpu@4 rv64imafdc > > > ID = 4, freq = 999.100 MHz: L1 cache, MMU > > > > > > Signed-off-by: Sagar Shrikant Kadam > > > Reviewed-by: Pragnesh Patel > > > --- > > > drivers/cpu/riscv_cpu.c | 12 > > > 1 file changed, 12 insertions(+) > > > > > > > Reviewed-by: Bin Meng > > Just noticed that you sent to the wrong U-Boot ML address. Please resend > this series to the ML. Thanks! > Yeah Bin, thanks for pointing it out. I received Undelivered notification about it. It was a mistake on my part. I am sending the v6 now Thanks & BR, Sagar > Regards, > Bin
RE: [PATCH 3/5] riscv: Do not build reset.c if SYSRESET is on
Hi Bin, > -Original Message- > From: Bin Meng > Sent: Friday, June 26, 2020 7:26 AM > To: Sagar Kadam > Cc: Rick Chen ; Simon Glass ; > Pragnesh Patel ; U-Boot Mailing List b...@lists.denx.de>; Bin Meng > Subject: Re: [PATCH 3/5] riscv: Do not build reset.c if SYSRESET is on > > [External Email] Do not click links or attachments unless you recognize the > sender and know the content is safe > > Hi Sagar, > > On Fri, Jun 26, 2020 at 1:14 AM Sagar Kadam > wrote: > > > > Hello Bin, > > > > > -Original Message- > > > From: Bin Meng > > > Sent: Tuesday, June 23, 2020 11:00 AM > > > To: Rick Chen ; Simon Glass > ; > > > Pragnesh Patel ; Sagar Kadam > > > ; U-Boot Mailing List > > > Cc: Bin Meng > > > Subject: [PATCH 3/5] riscv: Do not build reset.c if SYSRESET is on > > > > > > [External Email] Do not click links or attachments unless you > > > recognize the sender and know the content is safe > > > > > > From: Bin Meng > > > > > > SYSRESET uclass driver already provides all the reset APIs, hence > > > exclude our own ad-hoc reset.c implementation. > > > > > > Signed-off-by: Bin Meng > > > --- > > > > > > arch/riscv/lib/Makefile | 2 ++ > > > 1 file changed, 2 insertions(+) > > > > > > diff --git a/arch/riscv/lib/Makefile b/arch/riscv/lib/Makefile index > > > b5e9324..6c503ff 100644 > > > --- a/arch/riscv/lib/Makefile > > > +++ b/arch/riscv/lib/Makefile > > > @@ -20,7 +20,9 @@ obj-$(CONFIG_SBI) += sbi.o > > > obj-$(CONFIG_SBI_IPI) += sbi_ipi.o > > > endif > > > obj-y += interrupts.o > > > +ifeq ($(CONFIG_$(SPL_)SYSRESET),) > > > obj-y += reset.o > > > +endif > > > > I could see reset get's built when SYSRESET in enabled > > CC spl/arch/riscv/lib/interrupts.o > > CC spl/arch/riscv/lib/reset.o > > AS spl/arch/riscv/lib/setjmp.o > > > > This is because we don't enable CONFIG_SPL_SYSRESET in the board config. > For SPL, normally we don't need to reset. > Ok. Thanks for clarifying. Looks good. > > Should this have been? > > ifneq ($(CONFIG_$(SPL_)SYSRESET),) > > > > Regards, > Bin Reviewed-by: Sagar Kadam
RE: [PATCH 5/5] riscv: sifive: fu540: Add gpio-restart support
Hi, > -Original Message- > From: Bin Meng > Sent: Tuesday, June 23, 2020 11:00 AM > To: Rick Chen ; Simon Glass ; > Pragnesh Patel ; Sagar Kadam > ; U-Boot Mailing List > Cc: Bin Meng > Subject: [PATCH 5/5] riscv: sifive: fu540: Add gpio-restart support > > [External Email] Do not click links or attachments unless you recognize the > sender and know the content is safe > > From: Bin Meng > > The HiFive Unleashed board wires GPIO pin#10 to the input of the system > reset signal. This adds gpio reboot support. > > Signed-off-by: Bin Meng > --- > > board/sifive/fu540/Kconfig | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/board/sifive/fu540/Kconfig b/board/sifive/fu540/Kconfig index > 86193d7..6f65681 100644 > --- a/board/sifive/fu540/Kconfig > +++ b/board/sifive/fu540/Kconfig > @@ -65,5 +65,7 @@ config BOARD_SPECIFIC_OPTIONS # dummy > imply SMP > imply MISC > imply SIFIVE_OTP > + imply SYSRESET > + imply SYSRESET_GPIO > Looks Good. Reviewed-by: Sagar Kadam Tested-by: Sagar Kadam > endif > -- > 2.7.4
RE: [PATCH v2 1/5] dt-bindings: prci: add indexes for reset signals available in prci
Hi Jagan, > -Original Message- > From: Jagan Teki > Sent: Thursday, June 25, 2020 11:13 PM > To: Sagar Kadam > Cc: U-Boot-Denx ; Rick Chen ; > Paul Walmsley ( Sifive) ; Palmer Dabbelt > ; Anup Patel ; Atish Patra > ; Lukasz Majewski ; Pragnesh > Patel ; bin.m...@windriver.com; Simon Glass > ; Trevor Woerner ; Eugeniy > Paltsev ; Patrick Wildt > ; Weijie Gao ; Fabio > Estevam > Subject: Re: [PATCH v2 1/5] dt-bindings: prci: add indexes for reset signals > available in prci > > [External Email] Do not click links or attachments unless you recognize the > sender and know the content is safe > > On Thu, Jun 25, 2020 at 5:56 PM Sagar Shrikant Kadam > wrote: > > > > Add bit indexes for reset signals within the PRCI module > > on FU540-C000 SoC. > > The DDR and ethernet sub-system's have reset signals > > indicated by these reset indexes. > > > > Signed-off-by: Sagar Shrikant Kadam > > Reviewed-by: Pragnesh Patel > > Reviewed-by: Bin Meng > > --- > > include/dt-bindings/clock/sifive-fu540-prci.h | 8 > > 1 file changed, 8 insertions(+) > > > > diff --git a/include/dt-bindings/clock/sifive-fu540-prci.h b/include/dt- > bindings/clock/sifive-fu540-prci.h > > index 6a0b70a..1c03b09 100644 > > --- a/include/dt-bindings/clock/sifive-fu540-prci.h > > +++ b/include/dt-bindings/clock/sifive-fu540-prci.h > > @@ -15,4 +15,12 @@ > > #define PRCI_CLK_GEMGXLPLL2 > > #define PRCI_CLK_TLCLK3 > > > > +/* Reset bit indexes to be used by driver */ > > +#define PRCI_RST_DDR_CTRL_N0 > > +#define PRCI_RST_DDR_AXI_N 1 > > +#define PRCI_RST_DDR_AHB_N 2 > > +#define PRCI_RST_DDR_PHY_N 3 > > +/* bit 4 is reserved bit */ > > +#define PRCI_RST_RSVD_N4 > > +#define PRCI_RST_GEMGXL_N 5 > > #endif > > Do these bindings are synced from Linux? If Yes better to sync with a > particular commit or tag rather than patch. > No, these reset bindings are not synced from Linux. Thanks & Regards, Sagar > Jagan.
RE: [PATCH 3/5] riscv: Do not build reset.c if SYSRESET is on
Hello Bin, > -Original Message- > From: Bin Meng > Sent: Tuesday, June 23, 2020 11:00 AM > To: Rick Chen ; Simon Glass ; > Pragnesh Patel ; Sagar Kadam > ; U-Boot Mailing List > Cc: Bin Meng > Subject: [PATCH 3/5] riscv: Do not build reset.c if SYSRESET is on > > [External Email] Do not click links or attachments unless you recognize the > sender and know the content is safe > > From: Bin Meng > > SYSRESET uclass driver already provides all the reset APIs, hence > exclude our own ad-hoc reset.c implementation. > > Signed-off-by: Bin Meng > --- > > arch/riscv/lib/Makefile | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/riscv/lib/Makefile b/arch/riscv/lib/Makefile > index b5e9324..6c503ff 100644 > --- a/arch/riscv/lib/Makefile > +++ b/arch/riscv/lib/Makefile > @@ -20,7 +20,9 @@ obj-$(CONFIG_SBI) += sbi.o > obj-$(CONFIG_SBI_IPI) += sbi_ipi.o > endif > obj-y += interrupts.o > +ifeq ($(CONFIG_$(SPL_)SYSRESET),) > obj-y += reset.o > +endif I could see reset get's built when SYSRESET in enabled CC spl/arch/riscv/lib/interrupts.o CC spl/arch/riscv/lib/reset.o AS spl/arch/riscv/lib/setjmp.o Should this have been? ifneq ($(CONFIG_$(SPL_)SYSRESET),) Thanks & BR, Sagar > obj-y += setjmp.o > obj-$(CONFIG_$(SPL_)SMP) += smp.o > obj-$(CONFIG_SPL_BUILD)+= spl.o > -- > 2.7.4
RE: [PATCH v4 1/4] fu540: prci: add request and free clock handlers
Hi Bin,
> -Original Message-
> From: Sagar Kadam
> Sent: Thursday, June 25, 2020 10:17 AM
> To: Bin Meng
> Cc: U-Boot Mailing List ; Rick Chen
> ; Lukasz Majewski ; Jagan Teki
> ; Pragnesh Patel
> ; Anup Patel ; Simon
> Glass ; Sean Anderson
> Subject: RE: [PATCH v4 1/4] fu540: prci: add request and free clock handlers
>
> Hi Bin,
>
> > -Original Message-
> > From: Bin Meng
> > Sent: Thursday, June 25, 2020 4:51 AM
> > To: Sagar Kadam
> > Cc: U-Boot Mailing List ; Rick Chen
> > ; Lukasz Majewski ; Jagan Teki
> > ; Pragnesh Patel
> > ; Anup Patel ; Simon
> > Glass ; Sean Anderson
> > Subject: Re: [PATCH v4 1/4] fu540: prci: add request and free clock
> > handlers
> >
> > [External Email] Do not click links or attachments unless you
> > recognize the sender and know the content is safe
> >
> > Hi Sagar,
> >
> > On Wed, Jun 24, 2020 at 6:58 PM Sagar Kadam
> > wrote:
> > >
> > > Hi Bin,
> > >
> > > > -Original Message-
> > > > From: Bin Meng
> > > > Sent: Wednesday, June 24, 2020 6:50 AM
> > > > To: Sagar Kadam
> > > > Cc: U-Boot Mailing List ; Rick Chen
> > > > ; Lukasz Majewski ; Jagan
> Teki
> > > > ; Pragnesh Patel
> > > > ; Anup Patel ;
> > Simon
> > > > Glass ; Sean Anderson
> > > > Subject: Re: [PATCH v4 1/4] fu540: prci: add request and free
> > > > clock
> > handlers
> > > >
> > > > [External Email] Do not click links or attachments unless you
> > > > recognize
> > the
> > > > sender and know the content is safe
> > > >
> > > > Hi Sagar,
> > > >
> > > > On Sun, Jun 21, 2020 at 9:10 PM Sagar Shrikant Kadam
> > > > wrote:
> > > > >
> > > > > Add clk_request handler to check if a valid clock is requested.
> > > > > Here clk_free handler is added for debug purpose which will
> > > > > display details of clock passed to clk_free.
> > > > >
> > > > > Signed-off-by: Sagar Shrikant Kadam
> > > > > Reviewed-by: Pragnesh Patel
> > > > > ---
> > > > > drivers/clk/sifive/fu540-prci.c | 21 +
> > > > > 1 file changed, 21 insertions(+)
> > > > >
> > > > > diff --git a/drivers/clk/sifive/fu540-prci.c
> > > > > b/drivers/clk/sifive/fu540-prci.c index fe6e0d4..9a9ff6b 100644
> > > > > --- a/drivers/clk/sifive/fu540-prci.c
> > > > > +++ b/drivers/clk/sifive/fu540-prci.c
> > > > > @@ -686,6 +686,25 @@ static ulong
> > > > > sifive_fu540_prci_set_rate(struct
> > clk
> > > > *clk, ulong rate)
> > > > > return rate;
> > > > > }
> > > > >
> > > > > +static int sifive_fu540_prci_clk_request(struct clk *clk) {
> > > > > + debug("%s(clk=%p) (dev=%p, id=%lu)\n", __func__, clk, clk-
> >dev,
> > > > > + clk->id);
> > > > > +
> > > > > + if (clk->id >= ARRAY_SIZE(__prci_init_clocks))
> > > > > + return -EINVAL;
> > > > > +
> > > > > + return 0;
> > > > > +}
> > > > > +
> > > > > +static int sifive_fu540_prci_clk_free(struct clk *clk) {
> > > > > + debug("%s(clk=%p) (dev=%p, id=%lu)\n", __func__, clk, clk-
> >dev,
> > > > > + clk->id);
> > > > > +
> > > > > + return 0;
> > > > > +}
> > > >
> > > > It seems these 2 routines do not actually do anything? Is this for
> > debugging
> > > > purposes?
> > > >
> > > The sifive_fu540_prci_clk_request will check if the clock requested
> > > is valid
> > or not.
> > > While the sifive_fu540_prci_clk_free function is just for debug.
> > > Is it ok if I retain these in V5 or you have some other thought here.
> > >
> >
> > OK, but I suspect the parameter check in
> > sifive_fu540_prci_clk_request() is not necessary too as currently the
> > codes work well.
> >
>
> Ok. In that case I will than drop the check in sifive_fu540_prci_clk_request()
> and just keep the debug info.
>
> Thanks & BR,
> Sagar
>
Missed to add:
I had referred to other reference driver's and thought of keeping it.
So I'll drop this patch in V5 as it is not much value addition here.
Sorry for the confusion
Thanks & BR,
Sagar
> > Regards,
> > Bin
RE: [PATCH v4 1/4] fu540: prci: add request and free clock handlers
Hi Bin,
> -Original Message-
> From: Bin Meng
> Sent: Thursday, June 25, 2020 4:51 AM
> To: Sagar Kadam
> Cc: U-Boot Mailing List ; Rick Chen
> ; Lukasz Majewski ; Jagan Teki
> ; Pragnesh Patel
> ; Anup Patel ; Simon
> Glass ; Sean Anderson
> Subject: Re: [PATCH v4 1/4] fu540: prci: add request and free clock handlers
>
> [External Email] Do not click links or attachments unless you recognize the
> sender and know the content is safe
>
> Hi Sagar,
>
> On Wed, Jun 24, 2020 at 6:58 PM Sagar Kadam
> wrote:
> >
> > Hi Bin,
> >
> > > -Original Message-----
> > > From: Bin Meng
> > > Sent: Wednesday, June 24, 2020 6:50 AM
> > > To: Sagar Kadam
> > > Cc: U-Boot Mailing List ; Rick Chen
> > > ; Lukasz Majewski ; Jagan Teki
> > > ; Pragnesh Patel
> > > ; Anup Patel ;
> Simon
> > > Glass ; Sean Anderson
> > > Subject: Re: [PATCH v4 1/4] fu540: prci: add request and free clock
> handlers
> > >
> > > [External Email] Do not click links or attachments unless you recognize
> the
> > > sender and know the content is safe
> > >
> > > Hi Sagar,
> > >
> > > On Sun, Jun 21, 2020 at 9:10 PM Sagar Shrikant Kadam
> > > wrote:
> > > >
> > > > Add clk_request handler to check if a valid clock is requested.
> > > > Here clk_free handler is added for debug purpose which will display
> > > > details of clock passed to clk_free.
> > > >
> > > > Signed-off-by: Sagar Shrikant Kadam
> > > > Reviewed-by: Pragnesh Patel
> > > > ---
> > > > drivers/clk/sifive/fu540-prci.c | 21 +
> > > > 1 file changed, 21 insertions(+)
> > > >
> > > > diff --git a/drivers/clk/sifive/fu540-prci.c
> > > > b/drivers/clk/sifive/fu540-prci.c index fe6e0d4..9a9ff6b 100644
> > > > --- a/drivers/clk/sifive/fu540-prci.c
> > > > +++ b/drivers/clk/sifive/fu540-prci.c
> > > > @@ -686,6 +686,25 @@ static ulong sifive_fu540_prci_set_rate(struct
> clk
> > > *clk, ulong rate)
> > > > return rate;
> > > > }
> > > >
> > > > +static int sifive_fu540_prci_clk_request(struct clk *clk) {
> > > > + debug("%s(clk=%p) (dev=%p, id=%lu)\n", __func__, clk, clk->dev,
> > > > + clk->id);
> > > > +
> > > > + if (clk->id >= ARRAY_SIZE(__prci_init_clocks))
> > > > + return -EINVAL;
> > > > +
> > > > + return 0;
> > > > +}
> > > > +
> > > > +static int sifive_fu540_prci_clk_free(struct clk *clk) {
> > > > + debug("%s(clk=%p) (dev=%p, id=%lu)\n", __func__, clk, clk->dev,
> > > > + clk->id);
> > > > +
> > > > + return 0;
> > > > +}
> > >
> > > It seems these 2 routines do not actually do anything? Is this for
> debugging
> > > purposes?
> > >
> > The sifive_fu540_prci_clk_request will check if the clock requested is valid
> or not.
> > While the sifive_fu540_prci_clk_free function is just for debug.
> > Is it ok if I retain these in V5 or you have some other thought here.
> >
>
> OK, but I suspect the parameter check in
> sifive_fu540_prci_clk_request() is not necessary too as currently the
> codes work well.
>
Ok. In that case I will than drop the check in sifive_fu540_prci_clk_request()
and just keep the debug info.
Thanks & BR,
Sagar
> Regards,
> Bin
RE: [PATCH v4 1/4] fu540: prci: add request and free clock handlers
Hi Bin,
> -Original Message-
> From: Bin Meng
> Sent: Wednesday, June 24, 2020 6:50 AM
> To: Sagar Kadam
> Cc: U-Boot Mailing List ; Rick Chen
> ; Lukasz Majewski ; Jagan Teki
> ; Pragnesh Patel
> ; Anup Patel ; Simon
> Glass ; Sean Anderson
> Subject: Re: [PATCH v4 1/4] fu540: prci: add request and free clock handlers
>
> [External Email] Do not click links or attachments unless you recognize the
> sender and know the content is safe
>
> Hi Sagar,
>
> On Sun, Jun 21, 2020 at 9:10 PM Sagar Shrikant Kadam
> wrote:
> >
> > Add clk_request handler to check if a valid clock is requested.
> > Here clk_free handler is added for debug purpose which will display
> > details of clock passed to clk_free.
> >
> > Signed-off-by: Sagar Shrikant Kadam
> > Reviewed-by: Pragnesh Patel
> > ---
> > drivers/clk/sifive/fu540-prci.c | 21 +
> > 1 file changed, 21 insertions(+)
> >
> > diff --git a/drivers/clk/sifive/fu540-prci.c
> > b/drivers/clk/sifive/fu540-prci.c index fe6e0d4..9a9ff6b 100644
> > --- a/drivers/clk/sifive/fu540-prci.c
> > +++ b/drivers/clk/sifive/fu540-prci.c
> > @@ -686,6 +686,25 @@ static ulong sifive_fu540_prci_set_rate(struct clk
> *clk, ulong rate)
> > return rate;
> > }
> >
> > +static int sifive_fu540_prci_clk_request(struct clk *clk) {
> > + debug("%s(clk=%p) (dev=%p, id=%lu)\n", __func__, clk, clk->dev,
> > + clk->id);
> > +
> > + if (clk->id >= ARRAY_SIZE(__prci_init_clocks))
> > + return -EINVAL;
> > +
> > + return 0;
> > +}
> > +
> > +static int sifive_fu540_prci_clk_free(struct clk *clk) {
> > + debug("%s(clk=%p) (dev=%p, id=%lu)\n", __func__, clk, clk->dev,
> > + clk->id);
> > +
> > + return 0;
> > +}
>
> It seems these 2 routines do not actually do anything? Is this for debugging
> purposes?
>
The sifive_fu540_prci_clk_request will check if the clock requested is valid or
not.
While the sifive_fu540_prci_clk_free function is just for debug.
Is it ok if I retain these in V5 or you have some other thought here.
Thanks & BR,
Sagar
> Regards,
> Bin
RE: [PATCH v4 1/4] fu540: prci: add request and free clock handlers
Hi Rick, > -Original Message- > From: Rick Chen > Sent: Wednesday, June 24, 2020 7:16 AM > To: Bin Meng > Cc: Sagar Kadam ; U-Boot Mailing List b...@lists.denx.de>; Lukasz Majewski ; Jagan Teki > ; Pragnesh Patel > ; Anup Patel ; Simon > Glass ; Sean Anderson ; rick > ; Alan Kao ; > ycli...@andestech.com > Subject: Re: [PATCH v4 1/4] fu540: prci: add request and free clock handlers > > [External Email] Do not click links or attachments unless you recognize the > sender and know the content is safe > > Hi Bin > > > Hi Rick, > > > > On Wed, Jun 24, 2020 at 9:36 AM Rick Chen > wrote: > > > > > > Hi Sagar > > > > > > > > > > > Hello Rick, > > > > > > > > > -Original Message- > > > > > From: Rick Chen > > > > > Sent: Monday, June 22, 2020 7:24 AM > > > > > To: Sagar Kadam > > > > > Cc: U-Boot Mailing List ; Lukasz Majewski > > > > > ; Bin Meng ; Jagan Teki > > > > > ; Pragnesh Patel > > > > > ; Anup Patel ; > > > > > Simon Glass ; Sean Anderson > > > > > ; rick ; Alan Kao > > > > > ; ycli...@andestech.com > > > > > Subject: Re: [PATCH v4 1/4] fu540: prci: add request and free > > > > > clock handlers > > > > > > > > > > [External Email] Do not click links or attachments unless you > > > > > recognize the sender and know the content is safe > > > > > > > > > > Hi Sagar, > > > > > > > > > > > From: Sagar Shrikant Kadam [mailto:sagar.ka...@sifive.com] > > > > > > Sent: Sunday, June 21, 2020 9:10 PM > > > > > > To: u-boot@lists.denx.de > > > > > > Cc: Rick Jian-Zhi Chen(陳建志); lu...@denx.de; > > > > > > bmeng...@gmail.com; ja...@amarulasolutions.com; > > > > > > pragnesh.pa...@sifive.com; anup.pa...@wdc.com; > > > > > > s...@chromium.org; sean...@gmail.com; Sagar Shrikant Kadam > > > > > > Subject: [PATCH v4 1/4] fu540: prci: add request and free > > > > > > clock handlers > > > > > > > > > > > > Add clk_request handler to check if a valid clock is requested. > > > > > > Here clk_free handler is added for debug purpose which will > > > > > > display > > > > > details of clock passed to clk_free. > > > > > > > > > > > > Signed-off-by: Sagar Shrikant Kadam > > > > > > Reviewed-by: Pragnesh Patel > > > > > > --- > > > > > > > > > > This v4 series still have some conflicts with master. > > > > > Please check about it. > > > > > > > > > > Applying: fu540: prci: add request and free clock handlers > > > > > Applying: riscv: dts: hifive-unleashed-a00: add cpu aliases > > > > > Applying: riscv: cpu: fixes to display proper CPU features > > > > > error: patch failed: drivers/cpu/riscv_cpu.c:38 > > > > > error: drivers/cpu/riscv_cpu.c: patch does not apply Patch > > > > > failed at 0003 > > > > > riscv: cpu: fixes to display proper CPU features > > > > > > > > > > > > > Thanks for trying this out > > > > This series is dependent on following two patches [1] and [2] > > > > below which are part of "Add Sipeed Maix support." series [1] > > > > https://patchwork.ozlabs.org/patch/1295345 > > > > [2] https://patchwork.ozlabs.org/patch/1295346 > > > > and I also mentioned in cover-letter. Sorry If I missed to add > > > > some additional information there. > > > > > > > > The dependent are added like > > > > -u-boot master [commit 2b8692bac1e8]. > > > > -Patches [1] + [2]. > > > > -This series. > > > > > > According to this dependency I will apply yours in -next behind of > > > Sean's > > > > I just sent comments to this series, please hold on. > > OK. > Thanks for holding on. Yes, Bin has sent few comments. I will submit V5 for this. Thanks & BR, Sagar > Thanks, > Rick > > > > > Regards, > > Bin
RE: [PATCH 2/5] fu540: prci: use common reset indexes defined in binding header
Hi, > -Original Message- > From: Bin Meng > Sent: Wednesday, June 24, 2020 8:33 AM > To: Sagar Kadam > Cc: U-Boot Mailing List ; Rick Chen > ; Paul Walmsley ( Sifive) > ; Palmer Dabbelt ; > Anup Patel ; Atish Patra ; > Lukasz Majewski ; Pragnesh Patel > ; Jagan Teki ; > Simon Glass ; twoer...@gmail.com; Patrick Wildt > ; Fabio Estevam ; Weijie Gao > ; Eugeniy Paltsev > > Subject: Re: [PATCH 2/5] fu540: prci: use common reset indexes defined in > binding header > > [External Email] Do not click links or attachments unless you recognize the > sender and know the content is safe > > On Wed, Jun 24, 2020 at 11:01 AM Bin Meng > wrote: > > > > On Mon, Jun 22, 2020 at 8:28 PM Sagar Shrikant Kadam > > wrote: > > > > > > Indexes of reset signals available in PRCI driver are also defined > > > in include/dt-bindings/clock/sifive-fu540-prci.h. > > > So use those instead of defining new ones again within the > > > fu540-prci driver. > > > > > > Signed-off-by: Sagar Shrikant Kadam > > > Reviewed-by: Pragnesh Patel [A > > Forget to mention, please fix the [A in the next version > I will update fix for "[A". > > > --- > > > drivers/clk/sifive/fu540-prci.c | 16 ++-- > > > 1 file changed, 6 insertions(+), 10 deletions(-) > > > > > > > Reviewed-by: Bin Meng Thanks & BR, Sagar
RE: [PATCH v4 2/4] riscv: dts: hifive-unleashed-a00: add cpu aliases
Hi Bin, > -Original Message- > From: Bin Meng > Sent: Wednesday, June 24, 2020 6:52 AM > To: Sagar Kadam > Cc: U-Boot Mailing List ; Rick Chen > ; Lukasz Majewski ; Jagan Teki > ; Pragnesh Patel > ; Anup Patel ; Simon > Glass ; Sean Anderson > Subject: Re: [PATCH v4 2/4] riscv: dts: hifive-unleashed-a00: add cpu aliases > > [External Email] Do not click links or attachments unless you recognize the > sender and know the content is safe > > Hi Sagar, > > On Sun, Jun 21, 2020 at 9:10 PM Sagar Shrikant Kadam > wrote: > > > > Add cpu aliases to U-Boot specific dtsi for hifive-unleashed. > > Without aliases we see that the CPU device sequence numbers are set > > randomly and the cpu list/detail command will show it as follows: > > => cpu list > > 1: cpu@0 rv64imac > > 0: cpu@1 rv64imafdc > > 2: cpu@2 rv64imafdc > > 3: cpu@3 rv64imafdc > > 4: cpu@4 rv64imafdc > > Without this patch, my output does not show the cpu@0 node in the "cpu > list" output. > > Could you please clarify? I guess my explanation for your query in cover letter follow's here to. I will repost this based on spl. Thanks, Sagar > > > > > Seems like CPU probing with dm-model also relies on aliases as > > observed in case spi. The fu540-c000-u-boot.dtsi has cpu0/1/2/3/4 > > nodes and so adding corresponding aliases we can ensure that cpu > > devices are assigned proper sequence as follows: > > => cpu list > > 0: cpu@0 rv64imac > > 1: cpu@1 rv64imafdc > > 2: cpu@2 rv64imafdc > > 3: cpu@3 rv64imafdc > > 4: cpu@4 rv64imafdc > > > > Signed-off-by: Sagar Shrikant Kadam > > Reviewed-by: Pragnesh Patel > > --- > > Regards, > Bin
RE: [PATCH 4/5] sifive: reset: add DM based reset driver for SiFive SoC's
Hi,
> -Original Message-
> From: Sean Anderson
> Sent: Wednesday, June 24, 2020 10:49 AM
> To: Bin Meng
> Cc: Sagar Kadam ; U-Boot Mailing List b...@lists.denx.de>; Rick Chen ; Paul Walmsley (
> Sifive) ; Palmer Dabbelt
> ; Anup Patel ; Atish Patra
> ; Lukasz Majewski ; Pragnesh
> Patel ; Jagan Teki
> ; Simon Glass ;
> twoer...@gmail.com; Patrick Wildt ; Fabio Estevam
> ; Weijie Gao ; Eugeniy
> Paltsev
> Subject: Re: [PATCH 4/5] sifive: reset: add DM based reset driver for SiFive
> SoC's
>
> [External Email] Do not click links or attachments unless you recognize the
> sender and know the content is safe
>
> On 6/24/20 1:15 AM, Bin Meng wrote:
> > Hi Sean,
> >
> > On Wed, Jun 24, 2020 at 1:04 PM Sean Anderson
> wrote:
> >>
> >> On 6/24/20 1:01 AM, Bin Meng wrote:
> >>> Hi Sean,
> >>>
> >>> On Wed, Jun 24, 2020 at 12:17 PM Sean Anderson
> wrote:
> >>>>
> >>>> On 6/22/20 8:27 AM, Sagar Shrikant Kadam wrote:
> >>>>> The resets to DDR and ethernet sub-system are connected to PRCI
> >>>>> device reset control register, these reset signals are active low
> >>>>> and are held low at power-up. Add these reset producer and
> >>>>> consumer details needed by the reset driver.
> >>>>>
> >>>>> Signed-off-by: Sagar Shrikant Kadam
> >>>>> Reviewed-by: Pragnesh Patel
> >>>>> ---
> >>>>> arch/riscv/dts/fu540-c000-u-boot.dtsi | 10 ++
> >>>>> 1 file changed, 10 insertions(+)
> >>>>>
> >>>>> diff --git a/arch/riscv/dts/fu540-c000-u-boot.dtsi
> >>>>> b/arch/riscv/dts/fu540-c000-u-boot.dtsi
> >>>>> index 9bba554..b37241e 100644
> >>>>> --- a/arch/riscv/dts/fu540-c000-u-boot.dtsi
> >>>>> +++ b/arch/riscv/dts/fu540-c000-u-boot.dtsi
> >>>>> @@ -59,6 +59,16 @@
> >>>>> reg = <0x0 0x200 0x0 0xc>;
> >>>>> u-boot,dm-spl;
> >>>>> };
> >>>>> + prci: clock-controller@1000 {
> >>>>
> >>>> Shouldn't this have a compatible property?
> >>>
> >>> This is the U-Boot specific dts fragment. See fu540-c000.dtsi
> >>
> >> I ask because this node sits in /soc, and all the other nodes in /soc
> >> have compatible strings. Since this device is bound by the clock
> >> driver, perhaps it should be located under /soc/prci instead.
> >
> > fu540-c000.dtsi has everything you asked.
> >
>
> Ah, I didn't see that this was an extension. Looks good to me.
>
> --Sean
Thanks Bin and Sean for looking at it.
BR,
Sagar Kadam
RE: [PATCH v4 4/4] riscv: cpu: check and append L1 cache to cpu features
Hi Bin, > -Original Message- > From: Bin Meng > Sent: Wednesday, June 24, 2020 6:58 AM > To: Sagar Kadam ; Simon Glass > > Cc: U-Boot Mailing List ; Rick Chen > ; Lukasz Majewski ; Jagan Teki > ; Pragnesh Patel > ; Anup Patel ; Sean > Anderson > Subject: Re: [PATCH v4 4/4] riscv: cpu: check and append L1 cache to cpu > features > > [External Email] Do not click links or attachments unless you recognize the > sender and know the content is safe > > On Sun, Jun 21, 2020 at 9:10 PM Sagar Shrikant Kadam > wrote: > > > > All cpu cores within FU540-C000 having split I/D caches. > > Set the L1 cache feature bit using the i-cache-size as one of the > > property from device tree indicating that L1 cache is present > > on the cpu core. > > > > => cpu detail > > 0: cpu@0 rv64imac > > ID = 0, freq = 999.100 MHz: L1 cache > > 1: cpu@1 rv64imafdc > > ID = 1, freq = 999.100 MHz: L1 cache, MMU > > 2: cpu@2 rv64imafdc > > ID = 2, freq = 999.100 MHz: L1 cache, MMU > > 3: cpu@3 rv64imafdc > > ID = 3, freq = 999.100 MHz: L1 cache, MMU > > 4: cpu@4 rv64imafdc > > ID = 4, freq = 999.100 MHz: L1 cache, MMU > > > > Signed-off-by: Sagar Shrikant Kadam > > Reviewed-by: Pragnesh Patel > > --- > > drivers/cpu/riscv_cpu.c | 6 ++ > > 1 file changed, 6 insertions(+) > > > > diff --git a/drivers/cpu/riscv_cpu.c b/drivers/cpu/riscv_cpu.c > > index 8c4b5e7..ce722cb 100644 > > --- a/drivers/cpu/riscv_cpu.c > > +++ b/drivers/cpu/riscv_cpu.c > > @@ -35,6 +35,7 @@ static int riscv_cpu_get_info(struct udevice *dev, > struct cpu_info *info) > > int ret; > > struct clk clk; > > const char *mmu; > > + u32 split_cache_size; > > > > /* Zero out the frequency, in case sizeof(ulong) != sizeof(u32) */ > > info->cpu_freq = 0; > > @@ -57,6 +58,11 @@ static int riscv_cpu_get_info(struct udevice *dev, > struct cpu_info *info) > > if (mmu) > > info->features |= BIT(CPU_FEAT_MMU); > > > > + /* check if I/D cache is present */ > > + ret = dev_read_u32(dev, "i-cache-size", _cache_size); > > What about testing either "i-cache-size" and "d-cache-size", and if > either one exists, set CPU_FEAT_L1_CACHE > Ok. I will repost it with d-cache check as well. Thanks & BR, Sagar Kadam > > + if (!ret) > > + info->features |= BIT(CPU_FEAT_L1_CACHE); > > + > > return 0; > > } > > Regards, > Bin
RE: [PATCH v4 0/4] update clock handler and proper cpu features
Hi Bin,
> -Original Message-
> From: Bin Meng
> Sent: Wednesday, June 24, 2020 6:46 AM
> To: Sagar Kadam
> Cc: U-Boot Mailing List ; Rick Chen
> ; Lukasz Majewski ; Jagan Teki
> ; Pragnesh Patel
> ; Anup Patel ; Simon
> Glass ; Sean Anderson
> Subject: Re: [PATCH v4 0/4] update clock handler and proper cpu features
>
> [External Email] Do not click links or attachments unless you recognize the
> sender and know the content is safe
>
> Hi Sagar,
>
> On Sun, Jun 21, 2020 at 9:10 PM Sagar Shrikant Kadam
> wrote:
> >
> > U-Boot cmd "cpu detail" shows inconsistent CPU features and is missing
> > clk_request and free handlers.
> > The current "cpu detail" sometimes shows "Microcode" as a feature,
> > which is not the case with FU540-C000 on HiFive Unleashed board.
> >
> > Patch 1: add clk request handler to check if valid clock id is requested.
> > Patch 2: add cpu node aliases.
> > Patch 3: Correctly parse and update mmu-type.
> >
> > RISC-V core's on FU540-C000 SoC have separate instruction and data
> > (split)
> > L1 cache.
> > Patch 4:Use i-cache-size dt property as one of identifier to indicate a
> > split cache is available.
> >
> > I have picked few dependent patches from Sean's series from here [1]
> > and [2].
> >
> > These have applied on mainline U-Boot commit 2b8692bac1e8 ("Merge
> tag
> > 'efi-2020-07-rc5-2' of
> > https://gitlab.denx.de/u-boot/custodians/u-boot-efi;)
> >
> > Patch history:
> > =
> > V4:
> > 1. Rebased the series to mainline commit.
> > 2. Updated dependency list as few patches are now merged.
> > 3. Added U-Boot log of the flow i.e fsbl + fw_payload.bin
> > (Opensbi+U-Boot)
> >
> > V3:
> > 1. Included the cosmetic change as suggested
> >s/L1 feature/L1 cache feature/
> > 2. Added Reviewed-By tags
> >
> > V2:
> > 1. Incorporate review comments from Bin and Sean Anderson.
> >and dropped 2nd patch as similar work was already done in [1] and
> > [2]
> > 2 Add cpu node aliases to display cpu node's in sequence.
> > 3. Add fix to show mmu as available cpu feature.
> > 4. Check and append L1 cache feature.
> >
> > V1: Base version
> > Thanks to Vincent Chen for testing the V1
> > version of this series.
> >
> > [1] https://patchwork.ozlabs.org/patch/1295345
> > [2] https://patchwork.ozlabs.org/patch/1295346
> >
> > All these together is available here:
> > https://github.com/sagsifive/u-boot/commits/dev/sagark/clk-v4
> >
> > U-Boot log:
> > ===
> > SiFive FSBL: 2020-02-19-1081db9-dirty
> > Using new FSBL DTB now
> > HiFive-U-serial-#: 02c8
> > Loading boot payload
> >
> > OpenSBI v0.7-31-gd626037
> >_ _
> > / __ \ / | _ \_ _|
> > | | | |_ __ ___ _ __ | (___ | |_) || |
> > | | | | '_ \ / _ \ '_ \ \___ \| _ < | | | |__| | |_) | __/ | |
> > |) | |_) || |_
> > \/| .__/ \___|_| |_|_/|/_|
> > | |
> > |_|
> >
> > Platform Name : SiFive Freedom U540
> > Platform HART Features : RV64ACDFIMSU
> > Platform HART Count: 4
> > Current HART ID: 1
> > Firmware Base : 0x8000
> > Firmware Size : 100 KB
> > Runtime SBI Version: 0.2
> >
> > MIDELEG : 0x0222
> > MEDELEG : 0xb109
> > PMP0: 0x8000-0x8001 (A)
> > PMP1: 0x-0x007f (A,R,W,X)
> >
> >
> > U-Boot 2020.07-rc4-00084-gf824d2c (Jun 21 2020 - 04:58:40 -0700)
> >
> > CPU: rv64imac
> > Model: SiFive HiFive Unleashed A00
> > DRAM: 8 GiB
> > MMC: spi@1005:mmc@0: 0
> > In:serial@1001
> > Out: serial@1001
> > Err: serial@1001
> > Net: eth0: ethernet@1009
> > Hit any key to stop autoboot: 0
> > => cpu detail
> > 0: cpu@0 rv64imac
> > ID = 0, freq = 999.100 MHz: L1 cache
> > 1: cpu@1 rv64imafdc
> > ID = 1, freq = 999.100 MHz: L1 cache, MMU
> > 2: cpu@2 rv64imafdc
> > ID = 2, freq = 999.100 MHz: L1 cache, MMU
> > 3: cpu@3 rv64imafdc
> > ID = 3, freq = 999.100 MHz: L1 cache, MMU
> > 4: cpu@4 rv64imafdc
> > ID = 4, freq = 999.100 MHz:
RE: [PATCH v4 1/4] fu540: prci: add request and free clock handlers
Hello Rick,
> -Original Message-
> From: Rick Chen
> Sent: Monday, June 22, 2020 7:24 AM
> To: Sagar Kadam
> Cc: U-Boot Mailing List ; Lukasz Majewski
> ; Bin Meng ; Jagan Teki
> ; Pragnesh Patel
> ; Anup Patel ; Simon
> Glass ; Sean Anderson ; rick
> ; Alan Kao ;
> ycli...@andestech.com
> Subject: Re: [PATCH v4 1/4] fu540: prci: add request and free clock handlers
>
> [External Email] Do not click links or attachments unless you recognize the
> sender and know the content is safe
>
> Hi Sagar,
>
> > From: Sagar Shrikant Kadam [mailto:sagar.ka...@sifive.com]
> > Sent: Sunday, June 21, 2020 9:10 PM
> > To: u-boot@lists.denx.de
> > Cc: Rick Jian-Zhi Chen(陳建志); lu...@denx.de; bmeng...@gmail.com;
> > ja...@amarulasolutions.com; pragnesh.pa...@sifive.com;
> > anup.pa...@wdc.com; s...@chromium.org; sean...@gmail.com; Sagar
> > Shrikant Kadam
> > Subject: [PATCH v4 1/4] fu540: prci: add request and free clock
> > handlers
> >
> > Add clk_request handler to check if a valid clock is requested.
> > Here clk_free handler is added for debug purpose which will display
> details of clock passed to clk_free.
> >
> > Signed-off-by: Sagar Shrikant Kadam
> > Reviewed-by: Pragnesh Patel
> > ---
>
> This v4 series still have some conflicts with master.
> Please check about it.
>
> Applying: fu540: prci: add request and free clock handlers
> Applying: riscv: dts: hifive-unleashed-a00: add cpu aliases
> Applying: riscv: cpu: fixes to display proper CPU features
> error: patch failed: drivers/cpu/riscv_cpu.c:38
> error: drivers/cpu/riscv_cpu.c: patch does not apply Patch failed at 0003
> riscv: cpu: fixes to display proper CPU features
>
Thanks for trying this out
This series is dependent on following two patches [1]
and [2] below which are part of "Add Sipeed Maix support." series
[1] https://patchwork.ozlabs.org/patch/1295345
[2] https://patchwork.ozlabs.org/patch/1295346
and I also mentioned in cover-letter. Sorry If I missed to add some
additional information there.
The dependent are added like
-u-boot master [commit 2b8692bac1e8].
-Patches [1] + [2].
-This series.
I guess the PR for the series was sent earlier followed with some discussion
https://www.mail-archive.com/u-boot@lists.denx.de/msg370739.html
and I think this series was deferred in that PR.
Please let me know if you have some suggestions here?
Thanks & BR,
Sagar Kadam
> Thanks,
> Rick
>
> > drivers/clk/sifive/fu540-prci.c | 21 +
> > 1 file changed, 21 insertions(+)
> >
> > diff --git a/drivers/clk/sifive/fu540-prci.c
> > b/drivers/clk/sifive/fu540-prci.c index fe6e0d4..9a9ff6b 100644
> > --- a/drivers/clk/sifive/fu540-prci.c
> > +++ b/drivers/clk/sifive/fu540-prci.c
> > @@ -686,6 +686,25 @@ static ulong sifive_fu540_prci_set_rate(struct clk
> *clk, ulong rate)
> > return rate;
> > }
> >
> > +static int sifive_fu540_prci_clk_request(struct clk *clk) {
> > + debug("%s(clk=%p) (dev=%p, id=%lu)\n", __func__, clk, clk->dev,
> > + clk->id);
> > +
> > + if (clk->id >= ARRAY_SIZE(__prci_init_clocks))
> > + return -EINVAL;
> > +
> > + return 0;
> > +}
> > +
> > +static int sifive_fu540_prci_clk_free(struct clk *clk) {
> > + debug("%s(clk=%p) (dev=%p, id=%lu)\n", __func__, clk, clk->dev,
> > + clk->id);
> > +
> > + return 0;
> > +}
> > +
> > static int sifive_fu540_prci_enable(struct clk *clk) {
> > struct __prci_clock *pc;
> > @@ -755,6 +774,8 @@ static struct clk_ops sifive_fu540_prci_ops = {
> > .get_rate = sifive_fu540_prci_get_rate,
> > .enable = sifive_fu540_prci_enable,
> > .disable = sifive_fu540_prci_disable,
> > + .request = sifive_fu540_prci_clk_request,
> > + .rfree= sifive_fu540_prci_clk_free,
> > };
> >
> > static const struct udevice_id sifive_fu540_prci_ids[] = {
> > --
> > 2.7.4
> >
RE: [PATCH v3 0/4] update clock handler and proper cpu features
Hello Rick,
> -Original Message-
> From: Rick Chen
> Sent: Friday, June 19, 2020 1:26 PM
> To: Sagar Kadam
> Cc: U-Boot Mailing List ; Lukasz Majewski
> ; Bin Meng ; Jagan Teki
> ; Pragnesh Patel
> ; Anup Patel ; Simon
> Glass ; Sean Anderson ; rick
> ; ycli...@andestech.com; Alan Kao
>
> Subject: Re: [PATCH v3 0/4] update clock handler and proper cpu features
>
> [External Email] Do not click links or attachments unless you recognize the
> sender and know the content is safe
>
> Hi Sagar
>
> > From: Sagar Shrikant Kadam [mailto:sagar.ka...@sifive.com]
> > Sent: Thursday, June 04, 2020 6:45 PM
> > To: u-boot@lists.denx.de; Rick Jian-Zhi Chen(陳建志); lu...@denx.de
> > Cc: bmeng...@gmail.com; ja...@amarulasolutions.com;
> pragnesh.pa...@sifive.com; anup.pa...@wdc.com; s...@chromium.org;
> sean...@gmail.com; Sagar Shrikant Kadam
> > Subject: [PATCH v3 0/4] update clock handler and proper cpu features
> >
> > U-Boot cmd "cpu detail" shows inconsistent CPU features and is missing
> clk_request and free handlers.
> > The current "cpu detail" sometimes shows "Microcode" as a feature,
> which is not the case with FU540-C000 on HiFive Unleashed board.
> >
> > Patch 1: add clk request handler to check if valid clock id is requested.
> > Patch 2: add cpu node aliases.
> > Patch 3: Correctly parse and update mmu-type.
> >
> > RISC-V core's on FU540-C000 SoC have separate instruction and data
> (split)
> > L1 cache.
> > Patch 4:Use i-cache-size dt property as one of identifier to indicate a
> > split cache is available.
> >
> > I have picked few dependent patches from Sean's and Pragnesh's latest
> series from here [1]...[5].
> >
> > These have applied on mainline U-Boot commit 0d8f35b58cc8 ("Merge
> https://gitlab.denx.de/u-boot/custodians/u-boot-spi;)
> >
> > Patch history:
> > =
> > V3:
> > 1. Included the cosmetic change as suggested
> >s/L1 feature/L1 cache feature/
> > 2. Added Reviewed-By tags
> >
> > V2:
> > 1. Incorporate review comments from Bin and Sean Anderson.
> >and dropped 2nd patch as similar work was already done in [1] and [2]
> > 2 Add cpu node aliases to display cpu node's in sequence.
> > 3. Add fix to show mmu as available cpu feature.
> > 4. Check and append L1 cache feature.
> >
> > V1: Base version
> > Thanks to Vincent Chen for testing the V1
> > version of this series.
> >
> > [1] https://patchwork.ozlabs.org/patch/1295345
> > [2] https://patchwork.ozlabs.org/patch/1295346
> > [3] https://patchwork.ozlabs.org/patch/1300369
> > [4] https://patchwork.ozlabs.org/patch/1300370
> > [5] https://patchwork.ozlabs.org/patch/1300373
> >
> > All these together is available here:
> > https://github.com/sagsifive/u-boot/commits/dev/sagark/clk-v3
> >
> > Sagar Shrikant Kadam (4):
> > fu540: prci: add request and free clock handlers
> > riscv: dts: hifive-unleashed-a00: add cpu aliases
> > riscv: cpu: fixes to display proper CPU features
> > riscv: cpu: check and append L1 cache to cpu features
> >
> > arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi | 5 +
> > drivers/clk/sifive/fu540-prci.c | 21 +
> > drivers/cpu/riscv_cpu.c | 10 +-
> > 3 files changed, 35 insertions(+), 1 deletion(-)
>
>
> I am trying to apply to u-boot/master, but it fail as below:
> Applying: fu540: prci: add request and free clock handlers
> error: patch failed: drivers/clk/sifive/fu540-prci.c:581
> error: drivers/clk/sifive/fu540-prci.c: patch does not apply
> Patch failed at 0001 fu540: prci: add request and free clock handlers
>
> Please rebase master, I will sync to master later.
>
Sure, I will rebase and resend this series on master
Thanks & BR,
Sagar
> Thanks,
> Rick
>
> >
> > --
> > 2.7.4
> >
RE: [PATCH v2 4/4] riscv: cpu: check and append L1 cache to cpu features
Hi Pragnesh, > -Original Message- > From: Pragnesh Patel > Sent: Wednesday, May 27, 2020 8:10 PM > To: Sagar Kadam ; u-boot@lists.denx.de; > r...@andestech.com; lu...@denx.de > Cc: ja...@amarulasolutions.com; bmeng...@gmail.com; > sean...@gmail.com > Subject: RE: [PATCH v2 4/4] riscv: cpu: check and append L1 cache to cpu > features > > Hi Sagar, > > >-Original Message- > >From: Sagar Kadam > >Sent: 26 May 2020 22:39 > >To: u-boot@lists.denx.de; r...@andestech.com; lu...@denx.de > >Cc: ja...@amarulasolutions.com; bmeng...@gmail.com; Pragnesh Patel > >; sean...@gmail.com; Sagar Kadam > > > >Subject: [PATCH v2 4/4] riscv: cpu: check and append L1 cache to cpu > >features > > > >All cpu cores within FU540-C000 having split I/D caches. > >Set the L1 feature bit using the i-cache-size as one of the property > >from > > s/L1 feature/L1 cache feature Ok. Will update > > >device tree indicating that L1 cache is present on the cpu core. > > > >=> cpu detail > > 0: cpu@0 rv64imac > >ID = 0, freq = 999.100 MHz: L1 cache > > 1: cpu@1 rv64imafdc > >ID = 1, freq = 999.100 MHz: L1 cache, MMU > > 2: cpu@2 rv64imafdc > >ID = 2, freq = 999.100 MHz: L1 cache, MMU > > 3: cpu@3 rv64imafdc > >ID = 3, freq = 999.100 MHz: L1 cache, MMU > > 4: cpu@4 rv64imafdc > >ID = 4, freq = 999.100 MHz: L1 cache, MMU > > > >Signed-off-by: Sagar Shrikant Kadam > > Reviewed-by: Pragnesh Patel Thanks for the review's BR, Sagar Kadam
RE: [PATCH v2 1/4] fu540: prci: add request and free clock handlers
Hi Pragnesh,
> -Original Message-
> From: Pragnesh Patel
> Sent: Wednesday, May 27, 2020 7:41 PM
> To: Sagar Kadam ; u-boot@lists.denx.de;
> r...@andestech.com; lu...@denx.de
> Cc: ja...@amarulasolutions.com; bmeng...@gmail.com;
> sean...@gmail.com
> Subject: RE: [PATCH v2 1/4] fu540: prci: add request and free clock handlers
>
> >-----Original Message-
> >From: Sagar Kadam
> >Sent: 26 May 2020 22:39
> >To: u-boot@lists.denx.de; r...@andestech.com; lu...@denx.de
> >Cc: ja...@amarulasolutions.com; bmeng...@gmail.com; Pragnesh Patel
> >; sean...@gmail.com; Sagar Kadam
> >
> >Subject: [PATCH v2 1/4] fu540: prci: add request and free clock
> >handlers
> >
> >Add clk_request handler to check if a valid clock is requested, Here
> >clk_free handler is added for debug purpose which will display details
> >of clock passed to clk_free.
> >
> >Signed-off-by: Sagar Shrikant Kadam
> >---
> > drivers/clk/sifive/fu540-prci.c | 21 +
> > 1 file changed, 21 insertions(+)
> >
>
> Reviewed-by: Pragnesh Patel
>
Thanks for the review.
BR,
Sagar
> >diff --git a/drivers/clk/sifive/fu540-prci.c
> >b/drivers/clk/sifive/fu540-prci.c index 67e21b6..bf50ea2 100644
> >--- a/drivers/clk/sifive/fu540-prci.c
> >+++ b/drivers/clk/sifive/fu540-prci.c
> >@@ -581,6 +581,25 @@ static ulong sifive_fu540_prci_set_rate(struct clk
> >*clk, ulong rate)
> > return rate;
> > }
> >
> >+static int sifive_fu540_prci_clk_request(struct clk *clk) {
> >+debug("%s(clk=%p) (dev=%p, id=%lu)\n", __func__, clk, clk->dev,
> >+ clk->id);
> >+
> >+if (clk->id >= ARRAY_SIZE(__prci_init_clocks))
> >+return -EINVAL;
> >+
> >+return 0;
> >+}
> >+
> >+static int sifive_fu540_prci_clk_free(struct clk *clk) {
> >+debug("%s(clk=%p) (dev=%p, id=%lu)\n", __func__, clk, clk->dev,
> >+ clk->id);
> >+
> >+return 0;
> >+}
> >+
> > static int sifive_fu540_prci_probe(struct udevice *dev) {
> > int i, err;
> >@@ -612,6 +631,8 @@ static int sifive_fu540_prci_probe(struct udevice
> >*dev) static struct clk_ops sifive_fu540_prci_ops = {
> > .set_rate = sifive_fu540_prci_set_rate,
> > .get_rate = sifive_fu540_prci_get_rate,
> >+.request = sifive_fu540_prci_clk_request,
> >+.rfree= sifive_fu540_prci_clk_free,
> > };
> >
> > static const struct udevice_id sifive_fu540_prci_ids[] = {
> >--
> >2.7.4
RE: [PATCH v4 0/5] riscv: sifive/fu540: Enable SPI-NOR support
Hello Jagan, > -Original Message- > From: Jagan Teki > Sent: Thursday, April 23, 2020 10:31 PM > To: u-boot@lists.denx.de > Cc: Rick Chen ; Bin Meng ; > Bhargav Shah ; Sagar Kadam > ; linux-amar...@amarulasolutions.com; Jagan > Teki > Subject: [PATCH v4 0/5] riscv: sifive/fu540: Enable SPI-NOR support > > [External Email] Do not click links or attachments unless you recognize the > sender and know the content is safe > > This is series v4 for SPI-NOR support on SiFive FU540 platform with HiFive > Unleashed board. > > Here is the previous version changes[1]. > > All patches on top of u-boot-spi/master. > Thanks for posting v4 for spi-nor support. Tested the series above u-boot-spi/master on HiFive Unleashed and was able to verify it for both spi-nor and mmc Additionally just confirmed the opcodes nor is configured with post spi_nor_scan: == [QUAD mode in dt with spi-tx-bus-width: <4>] pp opcode = 0x34 [QUAD MODE] read opcode = 0x6c [QUAD MODE] erase opcode = 0x21 SPI-NOR: 1. erase entire flash: Pass 2. write entire flash: Pass 3. read entire flash: Pass 4. cmp 32MiB read back data: Pass 5. MMC: Booted Linux and dtb from mmc (so as to confirm data integrity from mmc) = [SPI MODE in dt with spi-tx-bus-width: <1> ] pp opcode = 0x12 [SPI MODE] read opcode = 0xc [SPI MODE] erase opcode = 0x21 SPI-NOR: 1. erase entire flash: Pass 2. write entire flash: Pass 3. read entire flash: Pass 4. cmp 32MiB read back data: Pass 5. MMC: Booted Linux and dtb from mmc (so as to confirm data integrity from mmc) Tested-by: Sagar Kadam Thanks & BR, Sagar Kadam > Changes for v4: > - add spi-mem exec_op > - rebase on master > Changes for v3: > - fixed QPP support > - dropped sf commands log > > [1] > https://patchwork.ozlabs.org/project/uboot/cover/20200420125238.9610-1- > ja...@amarulasolutions.com/ > > Any inputs? > Jagan. > > Jagan Teki (5): > spi: sifive: Add spi-mem exec op > spi: sifive: Fix format register proto field > spi: sifive: Fix QPP transfer > riscv: dts: hifive-unleashed-a00: Add -u-boot.dtsi > sifive: fu540: Enable spi-nor flash support > > .../dts/hifive-unleashed-a00-u-boot.dtsi | 11 ++ > board/sifive/fu540/Kconfig| 3 + > drivers/spi/spi-sifive.c | 156 +++--- > 3 files changed, 146 insertions(+), 24 deletions(-) create mode 100644 > arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi > > -- > 2.17.1
RE: [PATCH 3/3] spi: sifive: Fix format register proto field
Hi Bin, Jagan, Thanks Jagan for posting the patches to enable QUAD SPI-NOR on HiFive Unleashed along with other sequels. > -Original Message- > From: Bin Meng > Sent: Tuesday, April 21, 2020 4:44 AM > To: Jagan Teki > Cc: Vignesh R ; U-Boot Mailing List b...@lists.denx.de>; Suneel Garapati ; Sagar > Kadam ; Bhargav Shah > ; Simon Glass ; Tom > Rini ; linux-amarula amar...@amarulasolutions.com> > Subject: Re: [PATCH 3/3] spi: sifive: Fix format register proto field > > [External Email] Do not click links or attachments unless you recognize the > sender and know the content is safe > > On Mon, Apr 20, 2020 at 8:09 PM Jagan Teki > wrote: > > > > SiFive SPI controller has a proto bit field in frame format register > > which would be used to configure the SPI I/O protocol lines used on > > specific transfer. > > > > Right now the driver is configuring this proto using slave->mode which > > is used for data transfer and opcode, address vary depending on the > > particular transfer at runtime. > > > > Now the SPI framework supports per transfer I/O protocol lines, so use > > spi->proto instead of slave-mode. > > > > Signed-off-by: Jagan Teki > > --- > > drivers/spi/spi-sifive.c | 11 --- > > 1 file changed, 8 insertions(+), 3 deletions(-) > > > > This patch does not apply on top of u-boot/master. > > Please rebase and resend. I guess Bin, you will also have to add following two patch series [1] and [2] before this set. I tested this and other series with following dependency chain over u-boot/master(e4837da7828293ea49abc579f939c0f5c4b127c3) 1> 1-2-mtd-spi-nor-Enable-QE-bit-for-ISSI-flash.patch 2> spi-sifive-Tidy-up-dm_spi_slave_platdata-variable.patch 3> spi: Support SPI I/O protocol lines 4> riscv: sifive/fu540: Enable SPI-NOR support I could verify flash erase/read/write operations along with mmc spi. [1] https://patchwork.ozlabs.org/project/uboot/patch/20200420100607.23009-1-ja...@amarulasolutions.com/ [2] https://patchwork.amarulasolutions.com/patch/1083/ Thanks & BR, Sagar Kadam > > Regards, > Bin
RE: [PATCH 1/2] mtd: spi-nor: Enable QE bit for ISSI flash
Hi Jagan, > -Original Message- > From: Jagan Teki > Sent: Monday, April 20, 2020 9:58 PM > To: Sagar Kadam > Cc: Vignesh R ; u-boot@lists.denx.de; Bin Meng > ; linux-amar...@amarulasolutions.com > Subject: Re: [PATCH 1/2] mtd: spi-nor: Enable QE bit for ISSI flash > > [External Email] Do not click links or attachments unless you recognize the > sender and know the content is safe > > On Mon, Apr 20, 2020 at 9:56 PM Sagar Kadam > wrote: > > > > Hi Jagan, > > > > > -Original Message- > > > From: Jagan Teki > > > Sent: Monday, April 20, 2020 3:36 PM > > > To: Vignesh R ; u-boot@lists.denx.de > > > Cc: Bin Meng ; linux- > > > amar...@amarulasolutions.com; Jagan Teki > > > ; Sagar Kadam > > > > Subject: [PATCH 1/2] mtd: spi-nor: Enable QE bit for ISSI flash > > > > > > [External Email] Do not click links or attachments unless you > > > recognize the sender and know the content is safe > > > > > > Enable QE bit for ISSI flash chips. > > > > > > QE enablement logic is similar to what Micromax has, so reuse the > > > existing code itself. > > > > nits: s/Micromax/Macronix > > Will update while applying, thanks. Sure, no issues. Thanks & BR, Sagar Kadam
RE: [PATCH 2/2] mtd: spi-nor-ids: Enable 4B_OPCODES for is25wp256
Hi Jagan,
> -Original Message-
> From: Jagan Teki
> Sent: Monday, April 20, 2020 3:36 PM
> To: Vignesh R ; u-boot@lists.denx.de
> Cc: Bin Meng ; linux-
> amar...@amarulasolutions.com; Jagan Teki
> ; Sagar Kadam
> Subject: [PATCH 2/2] mtd: spi-nor-ids: Enable 4B_OPCODES for is25wp256
>
> [External Email] Do not click links or attachments unless you recognize the
> sender and know the content is safe
>
> IS25WP256 flash chips do support 4byte address opcodes,
> so enable support for it.
>
> Cc: Sagar Shrikant Kadam
> Signed-off-by: Jagan Teki
> ---
> drivers/mtd/spi/spi-nor-ids.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
> index 973b6f86c9..f95bfb59e6 100644
> --- a/drivers/mtd/spi/spi-nor-ids.c
> +++ b/drivers/mtd/spi/spi-nor-ids.c
> @@ -135,7 +135,8 @@ const struct flash_info spi_nor_ids[] = {
> { INFO("is25wp128", 0x9d7018, 0, 64 * 1024, 256,
> SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> { INFO("is25wp256", 0x9d7019, 0, 64 * 1024, 512,
> - SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> + SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
> + SPI_NOR_4B_OPCODES) },
Looks good thanks for including.
Reviewed-by: Sagar Kadam
Thanks & BR,
Sagar Kadam
> #endif
> #ifdef CONFIG_SPI_FLASH_MACRONIX /* MACRONIX */
> /* Macronix */
> --
> 2.17.1
RE: [PATCH 1/2] mtd: spi-nor: Enable QE bit for ISSI flash
Hi Jagan, > -Original Message- > From: Jagan Teki > Sent: Monday, April 20, 2020 3:36 PM > To: Vignesh R ; u-boot@lists.denx.de > Cc: Bin Meng ; linux- > amar...@amarulasolutions.com; Jagan Teki > ; Sagar Kadam > Subject: [PATCH 1/2] mtd: spi-nor: Enable QE bit for ISSI flash > > [External Email] Do not click links or attachments unless you recognize the > sender and know the content is safe > > Enable QE bit for ISSI flash chips. > > QE enablement logic is similar to what Micromax has, so reuse the existing > code itself. nits: s/Micromax/Macronix Thanks, Sagar Kadam > > Cc: Sagar Shrikant Kadam > Signed-off-by: Jagan Teki > --- > drivers/mtd/spi/spi-nor-core.c | 1 + > include/linux/mtd/spi-nor.h| 1 + > 2 files changed, 2 insertions(+) > > diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c > index 7b6ad495ac..e0f6e4d6c3 100644 > --- a/drivers/mtd/spi/spi-nor-core.c > +++ b/drivers/mtd/spi/spi-nor-core.c > @@ -325,6 +325,7 @@ static int set_4byte(struct spi_nor *nor, const struct > flash_info *info, > case SNOR_MFR_MICRON: > /* Some Micron need WREN command; all will accept it */ > need_wren = true; > + case SNOR_MFR_ISSI: > case SNOR_MFR_MACRONIX: > case SNOR_MFR_WINBOND: > if (need_wren) > diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h index > ec144a08d8..233fdc341a 100644 > --- a/include/linux/mtd/spi-nor.h > +++ b/include/linux/mtd/spi-nor.h > @@ -22,6 +22,7 @@ > #define SNOR_MFR_INTEL CFI_MFR_INTEL > #define SNOR_MFR_STCFI_MFR_ST /* ST Micro <--> Micron */ > #define SNOR_MFR_MICRONCFI_MFR_MICRON /* ST Micro <--> > Micron */ > +#define SNOR_MFR_ISSI CFI_MFR_PMC > #define SNOR_MFR_MACRONIX CFI_MFR_MACRONIX > #define SNOR_MFR_SPANSION CFI_MFR_AMD > #define SNOR_MFR_SST CFI_MFR_SST > -- > 2.17.1
RE: [U-Boot] [PATCH v2 5/5] sifive: fu540: Enable spi-nor flash support
Hi Jagan, > -Original Message- > From: Jagan Teki > Sent: Saturday, April 18, 2020 4:12 PM > To: Sagar Kadam > Cc: Bin Meng ; U-Boot Mailing List b...@lists.denx.de>; linux-amarula amar...@amarulasolutions.com>; pal...@dabbelt.com > Subject: Re: [U-Boot] [PATCH v2 5/5] sifive: fu540: Enable spi-nor flash > support > > [External Email] Do not click links or attachments unless you recognize the > sender and know the content is safe > > Hi Sagar, > > On Sat, Apr 18, 2020 at 4:05 PM Sagar Kadam > wrote: > > > > Hello Jagan, > > > > > -Original Message- > > > From: Jagan Teki > > > Sent: Saturday, April 18, 2020 1:11 AM > > > To: Sagar Kadam > > > Cc: Bin Meng ; U-Boot Mailing List > > b...@lists.denx.de>; linux-amarula > > amar...@amarulasolutions.com>; pal...@dabbelt.com > > > Subject: Re: [U-Boot] [PATCH v2 5/5] sifive: fu540: Enable spi-nor flash > > > support > > > > > > [External Email] Do not click links or attachments unless you recognize > the > > > sender and know the content is safe > > > > > > Hi Sagar, > > > > > > On Fri, Apr 17, 2020 at 11:50 PM Sagar Kadam > > > > wrote: > > > > > > > > Hello Jagan, > > > > > > > > > -Original Message- > > > > > From: Jagan Teki > > > > > Sent: Friday, April 17, 2020 1:30 PM > > > > > To: Sagar Kadam > > > > > Cc: Bin Meng ; U-Boot Mailing List > > > > b...@lists.denx.de>; linux-amarula > > > > amar...@amarulasolutions.com>; pal...@dabbelt.com > > > > > Subject: Re: [U-Boot] [PATCH v2 5/5] sifive: fu540: Enable spi-nor > flash > > > > > support > > > > > > > > > > [External Email] Do not click links or attachments unless you > recognize > > > the > > > > > sender and know the content is safe > > > > > > > > > > Hi Sagar, > > > > > > > > > > On Tue, Apr 7, 2020 at 9:48 PM Sagar Kadam > > > > > > wrote: > > > > > > > > > > > > Hello Jagan, > > > > > > > > > > > > > -Original Message- > > > > > > > From: Jagan Teki > > > > > > > Sent: Monday, April 6, 2020 9:30 PM > > > > > > > To: Sagar Kadam > > > > > > > Cc: Bin Meng ; Palmer Dabbelt > > > > > > > ; U-Boot Mailing List b...@lists.denx.de>; > > > > > > > linux- amarula > > > > > > > Subject: Re: [U-Boot] [PATCH v2 5/5] sifive: fu540: Enable spi-nor > > > > > > > flash support > > > > > > > > > > > > > > [External Email] Do not click links or attachments unless you > > > > > > > recognize the sender and know the content is safe > > > > > > > > > > > > > > Hi Sagar, > > > > > > > > > > > > > > On Sun, Apr 5, 2020 at 12:29 AM Sagar Kadam > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > Hello Jagan, > > > > > > > > > > > > > > > > > -Original Message- > > > > > > > > > From: Jagan Teki > > > > > > > > > Sent: Saturday, April 4, 2020 11:45 PM > > > > > > > > > To: Sagar Kadam > > > > > > > > > Cc: Bin Meng ; Palmer Dabbelt > > > > > > > > > ; U-Boot Mailing List > > b...@lists.denx.de>; > > > > > > > linux- > > > > > > > > > amarula > > > > > > > > > Subject: Re: [U-Boot] [PATCH v2 5/5] sifive: fu540: Enable > > > > > > > > > spi-nor flash support > > > > > > > > > > > > > > > > > > [External Email] Do not click links or attachments unless you > > > > > > > > > recognize > > > > > > > the > > > > > > > > > sender and know the content is safe > > > > > > > > > > > > > > > > > > Hi Sagar, > > > > > > > > > > > > > > > > > > On Mon, Nov 18, 2019 at 2:29 AM Sagar Kadam > > > > > > > > > > &g
RE: [U-Boot] [PATCH v2 5/5] sifive: fu540: Enable spi-nor flash support
Hello Jagan, > -Original Message- > From: Jagan Teki > Sent: Saturday, April 18, 2020 1:11 AM > To: Sagar Kadam > Cc: Bin Meng ; U-Boot Mailing List b...@lists.denx.de>; linux-amarula amar...@amarulasolutions.com>; pal...@dabbelt.com > Subject: Re: [U-Boot] [PATCH v2 5/5] sifive: fu540: Enable spi-nor flash > support > > [External Email] Do not click links or attachments unless you recognize the > sender and know the content is safe > > Hi Sagar, > > On Fri, Apr 17, 2020 at 11:50 PM Sagar Kadam > wrote: > > > > Hello Jagan, > > > > > -Original Message- > > > From: Jagan Teki > > > Sent: Friday, April 17, 2020 1:30 PM > > > To: Sagar Kadam > > > Cc: Bin Meng ; U-Boot Mailing List > > b...@lists.denx.de>; linux-amarula > > amar...@amarulasolutions.com>; pal...@dabbelt.com > > > Subject: Re: [U-Boot] [PATCH v2 5/5] sifive: fu540: Enable spi-nor flash > > > support > > > > > > [External Email] Do not click links or attachments unless you recognize > the > > > sender and know the content is safe > > > > > > Hi Sagar, > > > > > > On Tue, Apr 7, 2020 at 9:48 PM Sagar Kadam > > > wrote: > > > > > > > > Hello Jagan, > > > > > > > > > -Original Message- > > > > > From: Jagan Teki > > > > > Sent: Monday, April 6, 2020 9:30 PM > > > > > To: Sagar Kadam > > > > > Cc: Bin Meng ; Palmer Dabbelt > > > > > ; U-Boot Mailing List ; > > > > > linux- amarula > > > > > Subject: Re: [U-Boot] [PATCH v2 5/5] sifive: fu540: Enable spi-nor > > > > > flash support > > > > > > > > > > [External Email] Do not click links or attachments unless you > > > > > recognize the sender and know the content is safe > > > > > > > > > > Hi Sagar, > > > > > > > > > > On Sun, Apr 5, 2020 at 12:29 AM Sagar Kadam > > > > > > > > wrote: > > > > > > > > > > > > Hello Jagan, > > > > > > > > > > > > > -Original Message- > > > > > > > From: Jagan Teki > > > > > > > Sent: Saturday, April 4, 2020 11:45 PM > > > > > > > To: Sagar Kadam > > > > > > > Cc: Bin Meng ; Palmer Dabbelt > > > > > > > ; U-Boot Mailing List b...@lists.denx.de>; > > > > > linux- > > > > > > > amarula > > > > > > > Subject: Re: [U-Boot] [PATCH v2 5/5] sifive: fu540: Enable > > > > > > > spi-nor flash support > > > > > > > > > > > > > > [External Email] Do not click links or attachments unless you > > > > > > > recognize > > > > > the > > > > > > > sender and know the content is safe > > > > > > > > > > > > > > Hi Sagar, > > > > > > > > > > > > > > On Mon, Nov 18, 2019 at 2:29 AM Sagar Kadam > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > Hello Jagan/Bin, > > > > > > > > > > > > > > > > > -Original Message- > > > > > > > > > From: U-Boot On Behalf Of > Bin > > > > > Meng > > > > > > > > > Sent: Monday, November 11, 2019 8:02 PM > > > > > > > > > To: Jagan Teki > > > > > > > > > Cc: Palmer Dabbelt ( Sifive) ; U-Boot > > > > > > > > > Mailing > > > > > List > > > > > > > > > > > > > > > b...@lists.denx.de>; linux-amarula > > > > > > amar...@amarulasolutions.com> > > > > > > > > > Subject: Re: [U-Boot] [PATCH v2 5/5] sifive: fu540: Enable > > > > > > > > > spi-nor > > > > > flash > > > > > > > > > support > > > > > > > > > > > > > > > > > > Hi Jagan, > > > > > > > > > > > > > > > > > > On Sat, Nov 9, 2019 at 7:57 PM Jagan Teki > > > > > > > > > > > > > > > > wrote: > > > > > > > > &
RE: [U-Boot] [PATCH v2 5/5] sifive: fu540: Enable spi-nor flash support
Hello Jagan, > -Original Message- > From: Jagan Teki > Sent: Friday, April 17, 2020 1:30 PM > To: Sagar Kadam > Cc: Bin Meng ; U-Boot Mailing List b...@lists.denx.de>; linux-amarula amar...@amarulasolutions.com>; pal...@dabbelt.com > Subject: Re: [U-Boot] [PATCH v2 5/5] sifive: fu540: Enable spi-nor flash > support > > [External Email] Do not click links or attachments unless you recognize the > sender and know the content is safe > > Hi Sagar, > > On Tue, Apr 7, 2020 at 9:48 PM Sagar Kadam > wrote: > > > > Hello Jagan, > > > > > -Original Message- > > > From: Jagan Teki > > > Sent: Monday, April 6, 2020 9:30 PM > > > To: Sagar Kadam > > > Cc: Bin Meng ; Palmer Dabbelt > > > ; U-Boot Mailing List ; > > > linux- amarula > > > Subject: Re: [U-Boot] [PATCH v2 5/5] sifive: fu540: Enable spi-nor > > > flash support > > > > > > [External Email] Do not click links or attachments unless you > > > recognize the sender and know the content is safe > > > > > > Hi Sagar, > > > > > > On Sun, Apr 5, 2020 at 12:29 AM Sagar Kadam > > > > wrote: > > > > > > > > Hello Jagan, > > > > > > > > > -Original Message- > > > > > From: Jagan Teki > > > > > Sent: Saturday, April 4, 2020 11:45 PM > > > > > To: Sagar Kadam > > > > > Cc: Bin Meng ; Palmer Dabbelt > > > > > ; U-Boot Mailing List ; > > > linux- > > > > > amarula > > > > > Subject: Re: [U-Boot] [PATCH v2 5/5] sifive: fu540: Enable > > > > > spi-nor flash support > > > > > > > > > > [External Email] Do not click links or attachments unless you > > > > > recognize > > > the > > > > > sender and know the content is safe > > > > > > > > > > Hi Sagar, > > > > > > > > > > On Mon, Nov 18, 2019 at 2:29 AM Sagar Kadam > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > Hello Jagan/Bin, > > > > > > > > > > > > > -Original Message- > > > > > > > From: U-Boot On Behalf Of Bin > > > Meng > > > > > > > Sent: Monday, November 11, 2019 8:02 PM > > > > > > > To: Jagan Teki > > > > > > > Cc: Palmer Dabbelt ( Sifive) ; U-Boot > > > > > > > Mailing > > > List > > > > > > > > > > > b...@lists.denx.de>; linux-amarula > > > > amar...@amarulasolutions.com> > > > > > > > Subject: Re: [U-Boot] [PATCH v2 5/5] sifive: fu540: Enable > > > > > > > spi-nor > > > flash > > > > > > > support > > > > > > > > > > > > > > Hi Jagan, > > > > > > > > > > > > > > On Sat, Nov 9, 2019 at 7:57 PM Jagan Teki > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > Hi Bin, > > > > > > > > > > > > > > > > On Tue, Oct 29, 2019 at 3:50 PM Bin Meng > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > Hi Jagan, > > > > > > > > > > > > > > > > > > On Tue, Oct 29, 2019 at 5:38 PM Bin Meng > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > Hi Jagan, > > > > > > > > > > > > > > > > > > > > On Wed, Oct 16, 2019 at 10:58 PM Jagan Teki > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > HiFive Unleashed A00 support is25wp256 spi-nor > > > > > > > > > > > flash, So enable the same and add test result log > > > > > > > > > > > for future reference. > > > > > > > > > > > > > > > > > > > > > > Tested on SiFive FU540 board. > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Jagan Teki > > > > > > > > > > >
RE: [U-Boot] [PATCH v2 5/5] sifive: fu540: Enable spi-nor flash support
Hello Jagan,
> -Original Message-
> From: Jagan Teki
> Sent: Monday, April 6, 2020 9:30 PM
> To: Sagar Kadam
> Cc: Bin Meng ; Palmer Dabbelt
> ; U-Boot Mailing List ; linux-
> amarula
> Subject: Re: [U-Boot] [PATCH v2 5/5] sifive: fu540: Enable spi-nor flash
> support
>
> [External Email] Do not click links or attachments unless you recognize the
> sender and know the content is safe
>
> Hi Sagar,
>
> On Sun, Apr 5, 2020 at 12:29 AM Sagar Kadam
> wrote:
> >
> > Hello Jagan,
> >
> > > -Original Message-
> > > From: Jagan Teki
> > > Sent: Saturday, April 4, 2020 11:45 PM
> > > To: Sagar Kadam
> > > Cc: Bin Meng ; Palmer Dabbelt
> > > ; U-Boot Mailing List ;
> linux-
> > > amarula
> > > Subject: Re: [U-Boot] [PATCH v2 5/5] sifive: fu540: Enable spi-nor flash
> > > support
> > >
> > > [External Email] Do not click links or attachments unless you recognize
> the
> > > sender and know the content is safe
> > >
> > > Hi Sagar,
> > >
> > > On Mon, Nov 18, 2019 at 2:29 AM Sagar Kadam
>
> > > wrote:
> > > >
> > > >
> > > > Hello Jagan/Bin,
> > > >
> > > > > -Original Message-
> > > > > From: U-Boot On Behalf Of Bin
> Meng
> > > > > Sent: Monday, November 11, 2019 8:02 PM
> > > > > To: Jagan Teki
> > > > > Cc: Palmer Dabbelt ( Sifive) ; U-Boot Mailing
> List
> > > > > > > b...@lists.denx.de>; linux-amarula > > amar...@amarulasolutions.com>
> > > > > Subject: Re: [U-Boot] [PATCH v2 5/5] sifive: fu540: Enable spi-nor
> flash
> > > > > support
> > > > >
> > > > > Hi Jagan,
> > > > >
> > > > > On Sat, Nov 9, 2019 at 7:57 PM Jagan Teki
> > >
> > > > > wrote:
> > > > > >
> > > > > > Hi Bin,
> > > > > >
> > > > > > On Tue, Oct 29, 2019 at 3:50 PM Bin Meng
> > > wrote:
> > > > > > >
> > > > > > > Hi Jagan,
> > > > > > >
> > > > > > > On Tue, Oct 29, 2019 at 5:38 PM Bin Meng
>
> > > > > wrote:
> > > > > > > >
> > > > > > > > Hi Jagan,
> > > > > > > >
> > > > > > > > On Wed, Oct 16, 2019 at 10:58 PM Jagan Teki
> > > > > wrote:
> > > > > > > > >
> > > > > > > > > HiFive Unleashed A00 support is25wp256 spi-nor flash,
> > > > > > > > > So enable the same and add test result log for future
> > > > > > > > > reference.
> > > > > > > > >
> > > > > > > > > Tested on SiFive FU540 board.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Jagan Teki
> > > > > > > > > Reviewed-by: Bin Meng
> > > > > > > > > Tested-by: Bin Meng
> > > > > > > > > ---
> > > > > > > > > .../dts/hifive-unleashed-a00-u-boot.dtsi | 1 +
> > > > > > > > > board/sifive/fu540/Kconfig| 3 +++
> > > > > > > > > doc/board/sifive/fu540.rst| 19
> > > +++
> > > > > > > > > 3 files changed, 23 insertions(+)
> > > > > > > > >
> > > > > > > > > diff --git a/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> > > > > b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> > > > > > > > > index 25ec8265a5..d7a64134db 100644
> > > > > > > > > --- a/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> > > > > > > > > +++ b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> > > > > > > > > @@ -5,6 +5,7 @@
> > > > > > > > >
> > > > > > > > > / {
> > > > > > > > > aliases {
> > > > > > > > > + spi0 =
> > > > > > > > > spi2 =
> > > > > > > > > };
> > > > > > > > > };
> > > > > > > > > diff --git a/board/sifive/fu540/Kconfig
> > > b/
RE: [U-Boot] [PATCH v2 5/5] sifive: fu540: Enable spi-nor flash support
Hello Jagan,
> -Original Message-
> From: Jagan Teki
> Sent: Saturday, April 4, 2020 11:45 PM
> To: Sagar Kadam
> Cc: Bin Meng ; Palmer Dabbelt
> ; U-Boot Mailing List ; linux-
> amarula
> Subject: Re: [U-Boot] [PATCH v2 5/5] sifive: fu540: Enable spi-nor flash
> support
>
> [External Email] Do not click links or attachments unless you recognize the
> sender and know the content is safe
>
> Hi Sagar,
>
> On Mon, Nov 18, 2019 at 2:29 AM Sagar Kadam
> wrote:
> >
> >
> > Hello Jagan/Bin,
> >
> > > -Original Message-
> > > From: U-Boot On Behalf Of Bin Meng
> > > Sent: Monday, November 11, 2019 8:02 PM
> > > To: Jagan Teki
> > > Cc: Palmer Dabbelt ( Sifive) ; U-Boot Mailing List
> > > b...@lists.denx.de>; linux-amarula amar...@amarulasolutions.com>
> > > Subject: Re: [U-Boot] [PATCH v2 5/5] sifive: fu540: Enable spi-nor flash
> > > support
> > >
> > > Hi Jagan,
> > >
> > > On Sat, Nov 9, 2019 at 7:57 PM Jagan Teki
>
> > > wrote:
> > > >
> > > > Hi Bin,
> > > >
> > > > On Tue, Oct 29, 2019 at 3:50 PM Bin Meng
> wrote:
> > > > >
> > > > > Hi Jagan,
> > > > >
> > > > > On Tue, Oct 29, 2019 at 5:38 PM Bin Meng
> > > wrote:
> > > > > >
> > > > > > Hi Jagan,
> > > > > >
> > > > > > On Wed, Oct 16, 2019 at 10:58 PM Jagan Teki
> > > wrote:
> > > > > > >
> > > > > > > HiFive Unleashed A00 support is25wp256 spi-nor flash,
> > > > > > > So enable the same and add test result log for future
> > > > > > > reference.
> > > > > > >
> > > > > > > Tested on SiFive FU540 board.
> > > > > > >
> > > > > > > Signed-off-by: Jagan Teki
> > > > > > > Reviewed-by: Bin Meng
> > > > > > > Tested-by: Bin Meng
> > > > > > > ---
> > > > > > > .../dts/hifive-unleashed-a00-u-boot.dtsi | 1 +
> > > > > > > board/sifive/fu540/Kconfig| 3 +++
> > > > > > > doc/board/sifive/fu540.rst| 19
> +++
> > > > > > > 3 files changed, 23 insertions(+)
> > > > > > >
> > > > > > > diff --git a/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> > > b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> > > > > > > index 25ec8265a5..d7a64134db 100644
> > > > > > > --- a/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> > > > > > > +++ b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> > > > > > > @@ -5,6 +5,7 @@
> > > > > > >
> > > > > > > / {
> > > > > > > aliases {
> > > > > > > + spi0 =
> > > > > > > spi2 =
> > > > > > > };
> > > > > > > };
> > > > > > > diff --git a/board/sifive/fu540/Kconfig
> b/board/sifive/fu540/Kconfig
> > > > > > > index 5d65080429..c5a1bca03c 100644
> > > > > > > --- a/board/sifive/fu540/Kconfig
> > > > > > > +++ b/board/sifive/fu540/Kconfig
> > > > > > > @@ -26,6 +26,7 @@ config BOARD_SPECIFIC_OPTIONS # dummy
> > > > > > > imply CMD_FS_GENERIC
> > > > > > > imply CMD_NET
> > > > > > > imply CMD_PING
> > > > > > > + imply CMD_SF
> > > > > > > imply CLK_SIFIVE
> > > > > > > imply CLK_SIFIVE_FU540_PRCI
> > > > > > > imply DOS_PARTITION
> > > > > > > @@ -40,6 +41,8 @@ config BOARD_SPECIFIC_OPTIONS # dummy
> > > > > > > imply SIFIVE_SERIAL
> > > > > > > imply SPI
> > > > > > > imply SPI_SIFIVE
> > > > > > > + imply SPI_FLASH
> > > > > > > + imply SPI_FLASH_ISSI
> > > > > > > imply MMC
> > > > > > > imply MMC_SPI
> > > > > > > imply MMC_BROKEN_CD
> > > > > > > diff --git a/doc/board/sifive/fu540.rst
> b/doc/board/sifive/fu540.rst
>
RE: [U-Boot Patch v2 3/4] dts: u-boot.dtsi: override flash tx-rx width
Hello Jagan,
> -Original Message-
> From: Bin Meng
> Sent: Wednesday, February 19, 2020 9:59 PM
> To: Sagar Kadam
> Cc: U-Boot Mailing List ; Rick Chen
> ; Paul Walmsley ( Sifive) ;
> Jagan Teki ; Anup Patel
>
> Subject: Re: [U-Boot Patch v2 3/4] dts: u-boot.dtsi: override flash tx-rx
> width
>
> Hi Sagar,
>
> On Fri, Feb 7, 2020 at 2:43 AM Sagar Kadam
> wrote:
> >
> > Hello Bin,
> >
> > > -Original Message-
> > > From: Bin Meng
> > > Sent: Tuesday, February 4, 2020 5:43 PM
> > > To: Sagar Kadam
> > > Cc: U-Boot Mailing List ; Rick Chen
> > > ; Paul Walmsley ( Sifive)
> > > ; Jagan Teki
> ;
> > > Anup Patel
> > > Subject: Re: [U-Boot Patch v2 3/4] dts: u-boot.dtsi: override flash
> > > tx-rx width
> > >
> > > Hi Sagar,
> > >
> > > On Wed, Jan 29, 2020 at 2:02 AM Sagar Shrikant Kadam
> > > wrote:
> > > >
> > > > The hifive-unleashed-a00.dts has flash spi-tx/rx width set to
> > > > 4-bit mode. During sf probe, spi_nor_scan fails to read the JEDEC
> > > > ID with reg_proto set to SNOR_PROTO_1_1_1. Setting it to 1-bit
> > > > mode as of now will help read the JEDEC-ID and perform other flash
> operations.
> > >
> > > So previously with Jagan's series that did not have these changes in
> > > this commit, the flash driver worked well. I wonder what real issue
> > > was fixed in this commit?
> > >
> > Yes true, I had observed that flash device was working with Jagan's
> > series you are indicating here. The flash device was getting probed at cs
> 2/4/6/8 etc..
> > but it couldn't get detected on CS0 which is actually connected on the
> > board to the flash device.
> > With the check of spi->num_cs done in patch 2 of this series or the
> > one handled in commit 7bacce524d48 ("dm: spi: Check cs number before
> > accessing slaves") invalid chip select is taken care of and flash is
> > not detected on wrong chip selects, but spi transfer still fails as
> > the sifive-spi driver set's the SIFIVE_SPI_FMT_PROTO_QUAD mode based
> > on device tree information. While reading Device ID in spi_nor_scan
> > the reg proto is set to 1_1_1 bit mode and this contradicts here in the
> > driver
> due to which spi_nor_scan fails, due to which one cannot use the flash.
> > So for now I have added this override here to 1 bit mode so that users can
> use it.
> > Maybe I will update the commit message to indicate that this is
> > workaround for a bug in SPI driver for FU540 which currently is not able to
> handle QUAD mode operation.
> > Please let me know your views here.
> >
>
> Thanks for the details. Based on your description, I think there is something
> wrong with the SPI-NOR driver. Your change to 1 line only seems to be a
> workaround.
>
> Jagan, would you please comment?
>
It would be good if you could also share some input's here.
Thanks & BR,
Sagar Kadam
> Regards,
> Bin
RE: [PATCH v1 2/2] cpu: clk: riscv: populate proper CPU core clk frequency
Hello Sean,
> -Original Message-
> From: Sean Anderson
> Sent: Friday, February 21, 2020 11:48 AM
> To: Sagar Kadam ; Bin Meng
>
> Cc: U-Boot Mailing List ; Lukasz Majewski
> ; Anup Patel ; Paul Walmsley (
> Sifive) ; Vincent Chen
>
> Subject: Re: [PATCH v1 2/2] cpu: clk: riscv: populate proper CPU core clk
> frequency
>
> On 2/21/20 12:59 AM, Sagar Kadam wrote:
> >> What you were trying to do in this patch, I believe the following 2
> >> patches already did it.
> >>
> >> http://patchwork.ozlabs.org/patch/1236177/
> >> http://patchwork.ozlabs.org/patch/1236180/
> >>
> >
> > Thanks for sharing the links. Unfortunately I didn’t come across it.
> > I applied these two patches within my repo (assuming there are not
> > extra dependencies) and would like to share my observation:
> > The implementation in the patch links shared here read's clock dt
> > property in clk_get_by_index. If the cpu dt node doesn't contain clock
> > property it return's negative value and so the clk_get_rate here won't be be
> executed.
> >
> > + ret = clk_get_by_index(dev, 0, );
> > + if (!ret) {
> > + ret = clk_get_rate();
>
> This is working as designed. The idea is to use the clocks property if it
> exists
> and to fall back on clock-frequency otherwise.
Thanks for clarifying.
>
> > Thus when I tested this on hifive unleashed the "cpu detail" showed
> frequency as 0 Hz.
>
> This is because the cpu nodes in the hifive/fu540 device tree have neither a
> clock-frequency property or a clocks property.
>
Yes, I will add clocks dt property.
> > Please correct me if I am wrong, but IMHO here we can check for
> > negative return code [if (ret < 0)] instead of (!ret) and if "clocks"
> > is missing in dt property then get the clock driver using
> > uclass_get_device_by_driver->request the clock -> and get clock rate,
> > just like below
> >
> > - if (!ret) {
> > + if (ret < 0) {
> > + ret = uclass_get_device_by_driver(UCLASS_CLK,
> > +
> > DM_GET_DRIVER(sifive_fu540_prci),
> > + );
>
> This is again adding board-specific code to a generic driver. Add a
> UCLASS_CLOCK driver if you want to support clocks. That way there is no
> need for code like this.
Thanks for suggestion.
I will remove board-specific code from generic driver.
>
> > + clk.id = 0;
> > + ret = clk_request(dev, );
> > + if (ret < 0) {
> > + pr_err("%s: request to clock device
> > + failed...\n", __func__);
>
> I belive pr_err is supported for linux compatibility. New code should use
> log_*. This is also probably debug-level and not err-level.
Ok. I will replace pr_err with log_debug.
>
> > + return ret;
> > + }
> > +
> >
> > Also there is missing "include linux/err.h" which is needed by
> > IS_ERR_VALUE
>
> Yes, I noticed that when rebasing. It will be fixed in the next version of the
> series.
Thanks for updating.
BR,
Sagar Kadam
>
> > Please let me know if I can rebase and update my patches above the two
> > patch's you pointed to.
> >
> >> Regards,
> >> Bin
>
> --Sean
RE: [PATCH v1 1/2] fu540: prci: add request and free clock handlers
Hi Sean,
> -Original Message-
> From: Sean Anderson
> Sent: Friday, February 21, 2020 11:53 AM
> To: Sagar Kadam ; u-boot@lists.denx.de
> Cc: lu...@denx.de; bmeng...@gmail.com; anup.pa...@wdc.com; Paul
> Walmsley ( Sifive) ; Vincent Chen
>
> Subject: Re: [PATCH v1 1/2] fu540: prci: add request and free clock handlers
>
> On 2/18/20 11:13 AM, Sagar Shrikant Kadam wrote:
> > +static int sifive_fu540_prci_clk_free(struct clk *clk) {
> > + debug("%s(clk=%p) (dev=%p, id=%lu)\n", __func__, clk, clk->dev,
> > + clk->id);
> > +
> > + if (clk->id >= ARRAY_SIZE(__prci_init_clocks))
> > + return -EINVAL;
> > +
> > + return 0;
> > +}
> > +
>
> I don't think this function is necessary, since no struct clk should be
> passed to
> clk_free except one which was previously successfully requested.
>
Thanks for suggestion.
I can drop this id check and keep the debug message as done in other similar
drivers.
BR,
Sagar Kadam
> > static int sifive_fu540_prci_probe(struct udevice *dev) {
> > int i, err;
> > @@ -611,6 +633,8 @@ static int sifive_fu540_prci_probe(struct udevice
> > *dev) static struct clk_ops sifive_fu540_prci_ops = {
> > .set_rate = sifive_fu540_prci_set_rate,
> > .get_rate = sifive_fu540_prci_get_rate,
> > + .request = sifive_fu540_prci_clk_request,
> > + .rfree= sifive_fu540_prci_clk_free,
> > };
> >
> > static const struct udevice_id sifive_fu540_prci_ids[] = {
> >
>
> --Sean
RE: [PATCH v1 2/2] cpu: clk: riscv: populate proper CPU core clk frequency
Hello Bin,
> -Original Message-
> From: Bin Meng
> Sent: Wednesday, February 19, 2020 9:40 PM
> To: Sagar Kadam ; Sean Anderson
>
> Cc: U-Boot Mailing List ; Lukasz Majewski
> ; Anup Patel ; Paul Walmsley (
> Sifive) ; Vincent Chen
>
> Subject: Re: [PATCH v1 2/2] cpu: clk: riscv: populate proper CPU core clk
> frequency
>
> +Sean Anderson
>
> Hi Sagar,
>
> On Wed, Feb 19, 2020 at 12:13 AM Sagar Shrikant Kadam
> wrote:
> >
> > Fetch core clock frequency from prci if clock-frequency for CPU nodes
> > is missing in device tree, so that the cmd "#cpu detail" will show the
> > correct CPU frequency.
> >
> > U-Boot command "#cpu detail" is showing wrong frequency values.
> > This patch fixes this issue by getting the core clock set in prci driver
> > if clock-frequency is not added to CPU nodes in device tree.
> > It is tested on HiFive Unleashed A00 board.
> >
> > Signed-off-by: Sagar Shrikant Kadam
> > Tested-by: Vincent Chen
> > ---
> > drivers/cpu/riscv_cpu.c | 39
> ++-
> > 1 file changed, 38 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/cpu/riscv_cpu.c b/drivers/cpu/riscv_cpu.c
> > index 28ad0aa..eb5491f 100644
> > --- a/drivers/cpu/riscv_cpu.c
> > +++ b/drivers/cpu/riscv_cpu.c
> > @@ -9,6 +9,8 @@
> > #include
> > #include
> > #include
> > +#include
> > +#include
>
> It's wrong to include a SoC specific header file in a generic driver.
>
Thanks for review.
Ok. I will remove this.
>
> >
> > DECLARE_GLOBAL_DATA_PTR;
> >
> > @@ -25,11 +27,46 @@ static int riscv_cpu_get_desc(struct udevice *dev,
> char *buf, int size)
> > return 0;
> > }
> >
> > +static ulong riscv_get_clkrate(int clk_index)
> > +{
> > + int ret;
> > + struct udevice *dev;
> > + struct clk clk;
> > + ulong rate;
> > +
> > + ret = uclass_get_device_by_driver(UCLASS_CLK,
> > + DM_GET_DRIVER(sifive_fu540_prci),
> > + );
> > + if (ret < 0) {
> > + pr_err("%s: Could not get device driver\n", __func__);
> > + return ret;
> > + }
> > +
> > + clk.id = clk_index;
> > + ret = clk_request(dev, );
> > + if (ret < 0) {
> > + pr_err("%s: request to clock device failed...\n", __func__);
> > + return ret;
> > + }
> > +
> > + rate = clk_get_rate();
> > +
> > + clk_free();
> > +
> > + return rate;
> > +}
> > +
> > static int riscv_cpu_get_info(struct udevice *dev, struct cpu_info *info)
> > {
> > const char *mmu;
> > + int ret;
> >
> > - dev_read_u32(dev, "clock-frequency", (u32 *)>cpu_freq);
> > + ret = dev_read_u32(dev, "clock-frequency", (u32 *)>cpu_freq);
> > + if (ret) {
> > + /* if clock-frequency is missing in DT, read it from prci */
> > + debug("Fetch core clk configured by prci\n");
> > + info->cpu_freq = riscv_get_clkrate(PRCI_CLK_COREPLL);
> > + }
> >
> > mmu = dev_read_string(dev, "mmu-type");
> > if (!mmu)
> > --
>
> What you were trying to do in this patch, I believe the following 2
> patches already did it.
>
> http://patchwork.ozlabs.org/patch/1236177/
> http://patchwork.ozlabs.org/patch/1236180/
>
Thanks for sharing the links. Unfortunately I didn’t come across it.
I applied these two patches within my repo (assuming there are not
extra dependencies) and would like to share my observation:
The implementation in the patch links shared here read's clock dt property
in clk_get_by_index. If the cpu dt node doesn't contain clock property it
return's
negative value and so the clk_get_rate here won't be be executed.
+ ret = clk_get_by_index(dev, 0, );
+ if (!ret) {
+ ret = clk_get_rate();
Thus when I tested this on hifive unleashed the "cpu detail" showed frequency
as 0 Hz.
Please correct me if I am wrong, but IMHO here we can check for negative return
code [if (ret < 0)] instead of (!ret) and if "clocks" is missing in dt property
then get the clock
driver using uclass_get_device_by_driver->request the clock -> and get clock
rate, just like below
- if (!ret) {
+ if (ret < 0) {
+ ret = uclass_get_device_by_driver(UCLASS_CLK,
+
DM_GET_DRIVER(sifive_fu540_prci),
+ );
+ clk.id = 0;
+ ret = clk_request(dev, );
+ if (ret < 0) {
+ pr_err("%s: request to clock device failed...\n",
__func__);
+ return ret;
+ }
+
Also there is missing "include linux/err.h" which is needed by IS_ERR_VALUE
Please let me know if I can rebase and update my patches above the two patch's
you
pointed to.
> Regards,
> Bin
RE: [U-Boot Patch v2 4/4] bdinfo: fu540: print fdt base address for debugging
Hi Bin,
> -Original Message-
> From: Bin Meng
> Sent: Tuesday, February 4, 2020 5:43 PM
> To: Sagar Kadam
> Cc: U-Boot Mailing List ; Rick Chen
> ; Paul Walmsley ( Sifive) ;
> Jagan Teki ; Anup Patel
>
> Subject: Re: [U-Boot Patch v2 4/4] bdinfo: fu540: print fdt base address for
> debugging
>
> Hi Sagar,
>
> On Wed, Jan 29, 2020 at 2:02 AM Sagar Shrikant Kadam
> wrote:
> >
> > Add fdt->gd info to bdinfo so that it is useful for debugging and
> > easily use it with fdt util.
>
> The commit title should be tagged with "riscv: bdinfo" as it is not
> fu540 specific.
>
Thanks for the Reviewed-by tag.
I will include the change in next series
BR,
Sagar
> >
> > Signed-off-by: Sagar Shrikant Kadam
> > ---
> > cmd/bdinfo.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/cmd/bdinfo.c b/cmd/bdinfo.c index d6a7175..96892b3 100644
> > --- a/cmd/bdinfo.c
> > +++ b/cmd/bdinfo.c
> > @@ -433,6 +433,7 @@ int do_bdinfo(cmd_tbl_t *cmdtp, int flag, int argc,
> char * const argv[])
> > print_bi_dram(bd);
> > print_num("relocaddr", gd->relocaddr);
> > print_num("reloc off", gd->reloc_off);
> > + print_num("fdt_blob", (ulong)gd->fdt_blob);
> > print_eth_ip_addr();
> > print_baudrate();
> >
> > --
>
> Other than above,
> Reviewed-by: Bin Meng
>
> Regards,
> Bin
RE: [U-Boot Patch v2 3/4] dts: u-boot.dtsi: override flash tx-rx width
Hello Bin,
> -Original Message-
> From: Bin Meng
> Sent: Tuesday, February 4, 2020 5:43 PM
> To: Sagar Kadam
> Cc: U-Boot Mailing List ; Rick Chen
> ; Paul Walmsley ( Sifive) ;
> Jagan Teki ; Anup Patel
>
> Subject: Re: [U-Boot Patch v2 3/4] dts: u-boot.dtsi: override flash tx-rx
> width
>
> Hi Sagar,
>
> On Wed, Jan 29, 2020 at 2:02 AM Sagar Shrikant Kadam
> wrote:
> >
> > The hifive-unleashed-a00.dts has flash spi-tx/rx width set to 4-bit
> > mode. During sf probe, spi_nor_scan fails to read the JEDEC ID with
> > reg_proto set to SNOR_PROTO_1_1_1. Setting it to 1-bit mode as of now
> > will help read the JEDEC-ID and perform other flash operations.
>
> So previously with Jagan's series that did not have these changes in this
> commit, the flash driver worked well. I wonder what real issue was fixed in
> this commit?
>
Yes true, I had observed that flash device was working with Jagan's series
you are indicating here. The flash device was getting probed at cs 2/4/6/8 etc..
but it couldn't get detected on CS0 which is actually connected on the board
to the flash device.
With the check of spi->num_cs done in patch 2 of this series or the one handled
in commit 7bacce524d48 ("dm: spi: Check cs number before accessing slaves")
invalid chip select is taken care of and flash is not detected on wrong chip
selects,
but spi transfer still fails as the sifive-spi driver set's the
SIFIVE_SPI_FMT_PROTO_QUAD
mode based on device tree information. While reading Device ID in spi_nor_scan
the
reg proto is set to 1_1_1 bit mode and this contradicts here in the driver due
to which
spi_nor_scan fails, due to which one cannot use the flash.
So for now I have added this override here to 1 bit mode so that users can use
it.
Maybe I will update the commit message to indicate that this is workaround for
a bug
in SPI driver for FU540 which currently is not able to handle QUAD mode
operation.
Please let me know your views here.
Thanks & BR,
Sagar
> >
> > Signed-off-by: Sagar Shrikant Kadam
> > ---
> > arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi | 8
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> > b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> > index d7a6413..dae9f87 100644
> > --- a/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> > +++ b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> > @@ -9,3 +9,11 @@
> > spi2 =
> > };
> > };
> > +
> > + {
> > + flash@0 {
> > + spi-tx-bus-width = <1>;
> > + spi-rx-bus-width = <1>;
> > + };
> > +};
> > +
>
> Regards,
> Bin
RE: [U-Boot Patch v2 2/4] spi: fu540: add claim and release method to spi-sifive.c
Hello Bin,
> -Original Message-
> From: Bin Meng
> Sent: Tuesday, February 4, 2020 5:43 PM
> To: Sagar Kadam
> Cc: U-Boot Mailing List ; Rick Chen
> ; Paul Walmsley ( Sifive) ;
> Jagan Teki ; Anup Patel
>
> Subject: Re: [U-Boot Patch v2 2/4] spi: fu540: add claim and release method
> to spi-sifive.c
>
> Hi Sagar,
>
> On Wed, Jan 29, 2020 at 2:02 AM Sagar Shrikant Kadam
> wrote:
> >
> > Add missing bus claim/release method to spi driver for HiFive
> > Unleashed, and handle num_cs generously so that it generates an error
> > if invalid cs number is passed to sf probe.
>
> Is adding the claim/release method the fix to the weird "sf probe 0:2/4/6/8"
> issue?
>
Please see below.
> >
> > Signed-off-by: Sagar Shrikant Kadam
> > ---
> > drivers/spi/spi-sifive.c | 36
> > 1 file changed, 36 insertions(+)
> >
> > diff --git a/drivers/spi/spi-sifive.c b/drivers/spi/spi-sifive.c index
> > 969bd4b..f990ad6 100644
> > --- a/drivers/spi/spi-sifive.c
> > +++ b/drivers/spi/spi-sifive.c
> > @@ -186,6 +186,36 @@ static void sifive_spi_tx(struct sifive_spi *spi, const
> u8 *tx_ptr)
> > writel(tx_data, spi->regs + SIFIVE_SPI_REG_TXDATA); }
> >
> > +static int sifive_spi_claim_bus(struct udevice *dev) {
> > + int ret;
> > + struct udevice *bus = dev->parent;
> > + struct sifive_spi *spi = dev_get_priv(bus);
> > + struct dm_spi_slave_platdata *slave =
> > +dev_get_parent_platdata(dev);
> > +
> > + if (!(slave->cs < spi->num_cs)) {
>
> slave->cs >= spi->num_cs
>
> But there is already check added recently in the spi-uclass driver, see below:
>
> commit 7bacce524d48594dae399f9ee9280ab105f6c8cf
> Author: Bin Meng
> Date: Mon Sep 9 06:00:02 2019 -0700
>
> dm: spi: Check cs number before accessing slaves
>
> Add chip select number check in spi_find_chip_select().
>
> Signed-off-by: Bin Meng
> Tested-by: Jagan Teki # SoPine
>
> Adding check in the sifive spi driver seems to unnecessary. Could you please
> confirm?
>
Ahh!!. Thanks for the pointer Bin.
This V2 patch here is based on commit c05b38df477a("common: fix regression
on block cache init"), so didn't come across the patch you pointed out.
So for now we can skip the check in sifive spi driver.
> > + printf("Invalid cs number = %d\n", slave->cs);
> > + return -EINVAL;
> > + }
> > +
> > + sifive_spi_prep_device(spi, slave);
> > +
> > + ret = sifive_spi_set_cs(spi, slave);
> > + if (ret)
> > + return ret;
> > +
> > + return 0;
> > +}
> > +
> > +static int sifive_spi_release_bus(struct udevice *dev) {
> > + struct sifive_spi *spi = dev_get_priv(dev->parent);
> > +
> > + sifive_spi_clear_cs(spi);
> > +
> > + return 0;
> > +}
>
> What was done in the sifive_spi_claim_bus / sifive_spi_release_bus seems to
> be already done in sifive_spi_xfer(). See flags testing against SPI_XFER_BEGIN
> and SPI_XFER_END.
>
> Could you please explain a little bit on why adding these 2 fixes things?
>
What I saw was that sf probe was detecting flash even at wrong chip select
inputs,
Like sf probe 0:2/4/6/.. this indicated that a check to validate chip selects
needs to be
there. The gist of adding the claim function was to introduce this chip select
check.
The code within SPI_XFER_BEGIN and END functions missed this check.
Now that the commit your pointed 7bacce524d48 handles this, I think
we can drop this check as of now.
> > +
> > static int sifive_spi_xfer(struct udevice *dev, unsigned int bitlen,
> >const void *dout, void *din, unsigned long
> > flags) { @@ -345,6 +375,10 @@ static int sifive_spi_probe(struct
> > udevice *bus)
> > /* init the sifive spi hw */
> > sifive_spi_init_hw(spi);
> >
> > + /* Fetch number of chip selects from DT if present */
> > + ret = dev_read_u32_default(bus, "num-cs", spi->num_cs);
> > + spi->num_cs = ret;
>
> spi->num_cs is already assigned a value in sifive_spi_init_hw(), Why
> do we override the value using DT's?
>
Yes, spi_init_hw does initialise the spi->num_cs by reading the register.
For QSPI0 and QSPI2 it is set to 1 (as per the cs_width). But for QSPI1 it is
set to 4. Consider a case where user wishes to populate only 1 chip select for
QSPI1
then it can be done in respective -dts file and c
RE: [U-Boot Patch v2 1/4] fu540: dtsi: spi: add num-cs info to device tree
Hello Bin,
> -Original Message-
> From: Bin Meng
> Sent: Tuesday, February 4, 2020 5:43 PM
> To: Sagar Kadam
> Cc: U-Boot Mailing List ; Rick Chen
> ; Paul Walmsley ( Sifive) ;
> Jagan Teki ; Anup Patel
>
> Subject: Re: [U-Boot Patch v2 1/4] fu540: dtsi: spi: add num-cs info to device
> tree
>
> Hi Sagar,
>
> On Wed, Jan 29, 2020 at 2:02 AM Sagar Shrikant Kadam
> wrote:
> >
> > Add the number of chip select information to spi nodes which can be
> > used by spi-uclass for error handling if invalid cs number passed from
> > command.
> >
> > Signed-off-by: Sagar Shrikant Kadam
> > ---
> > arch/riscv/dts/fu540-c000.dtsi | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/arch/riscv/dts/fu540-c000.dtsi
> > b/arch/riscv/dts/fu540-c000.dtsi index afa43c7..9c6ab21 100644
> > --- a/arch/riscv/dts/fu540-c000.dtsi
> > +++ b/arch/riscv/dts/fu540-c000.dtsi
> > @@ -191,6 +191,7 @@
> > clocks = < PRCI_CLK_TLCLK>;
> > #address-cells = <1>;
> > #size-cells = <0>;
> > + num-cs = <1>;
>
> Why is this necessary? I can't find the codes that handle the num-cs
> property.
The code handling num-cs is a part of patch 2. I intended to keep it separate
thinking better to isolate dt and c files patches. Please let me know if I need
to keep it together.
> In the SiFive SPI driver, num_cs is determined from register
> SIFIVE_SPI_REG_CSDEF.
>
The SiFive SPI driver does read the num_cs defined in the register you
mentioned.
but it's hard defined with cs_width, eg: QSPI0 = 1, QSPI1 = 4, QSPI2 = 1.
I have added the option after sifive_spi_init_hw to read from device tree as
well
so that if the user want's to change the chip select's (less than that defined
in
SIFIVE_SPI_REG_CSDEF) then it can be done in hifive-unleashed-a00.dtsi
Please let me know your thoughts over here.
BR,
Sagar
> > status = "disabled";
> > };
> > qspi1: spi@10041000 {
> > @@ -202,6 +203,7 @@
> > clocks = < PRCI_CLK_TLCLK>;
> > #address-cells = <1>;
> > #size-cells = <0>;
> > + num-cs = <1>;
> > status = "disabled";
> > };
> > qspi2: spi@1005 {
> > @@ -212,6 +214,7 @@
> > clocks = < PRCI_CLK_TLCLK>;
> > #address-cells = <1>;
> > #size-cells = <0>;
> > + num-cs = <1>;
> > status = "disabled";
> > };
> > eth0: ethernet@1009 {
> > --
>
> Regards,
> Bin
RE: [U-Boot Patch v2 0/4] Fix currently available support for flash on HiFive Unleashed
Hello Bin,
> -Original Message-
> From: Bin Meng
> Sent: Tuesday, February 4, 2020 5:21 PM
> To: Sagar Kadam
> Cc: U-Boot Mailing List ; Rick Chen
> ; Paul Walmsley ( Sifive) ;
> Jagan Teki ; Anup Patel
>
> Subject: Re: [U-Boot Patch v2 0/4] Fix currently available support for flash
> on
> HiFive Unleashed
>
> Hi Sagar,
>
> On Wed, Jan 29, 2020 at 2:02 AM Sagar Shrikant Kadam
> wrote:
> >
> > Currently device ID for flash mounted on HiFive Unleashed is added to
> > U-Boot. Also there are few patches about to go in mainline (Thanks to
> > Jagan Tekki and Bin Meng).
> >
> > This series addresses few issues discussed there:
> > Patch 1:Add num-cs to device tree which is used by spi-uclass to detect
> > valid chip select numbers
> > Patch 2:Handles valid chip selects only. Flash device is now detected only
> > on chip select 0.
> > Patch 3:Over-ride spi tx/rx width specified in hifive-unleshed-a00.dts file
> > from 4 to 1 in corresponding -u-boot.dtsi
> >
>
> Thank you for fixing all these SPI flash issues!
>
> > This series is based on mainline commit c05b38df477a ("common: fix
> > regression on block cache init") and two below mentioned patches from
> > [1] [U-Boot,v2,4/5] riscv: dts: hifive-unleashed-a00: Add -u-boot.dtsi
> > [U-Boot,v2,5/5] sifive: fu540: Enable spi-nor flash support
> >
> > [1] https://patchwork.ozlabs.org/patch/1177979/
> >
> > The above series is available for testing here[2] [2]
> > https://github.com/sagsifive/u-boot/tree/dev/sagark/test_spi-nor_v2
> >
> > Change History:
> > V1-V2:
> > 1. Dropped 6th and 7th patch sent in V1 from this series so as to separate
> >out spi-nor related changes in different series and avoid adding TODO
> >fixes to spi-nor-core framework.
>
> Did you resend the 6th and 7th patches as a separate series? I can't find
> them on the ML.
>
Thanks for your review Bin.
I have differed 6th and 7th patches as of now, as these could be handled
separately as it contained a TODO part which was not suitable to be introduced
into the spi-nor framework. So for now, I have added a workaround in the 3rd
patch
using which one can a working flash support.
BR,
Sagar
> > 2. Removed patch to include -uboot.dts, as it gets automatically included.
> > 3. Over-ride tx/rx width from hifive-unleashed-a00.dts using hifive
> >-unleashed-a00-u-boot.dtsi
> > 4. Print fdt base address in board info for debugging.
> >
> > V1: First version of series
> >
> >
> > Log for reference= Flash
> detection
> > only at valid Chip select => sf probe 0:0
> > SF: Detected is25wp256 with page size 256 Bytes, erase size 4 KiB,
> > total 32 MiB => sf probe 0:1 Invalid cs number = 1 Failed to
> > initialize SPI flash at 0:1 (error -22) => sf probe 0:2 Invalid cs
> > number = 2 Failed to initialize SPI flash at 0:2 (error -22) => sf
> > probe 0:0
> > SF: Detected is25wp256 with page size 256 Bytes, erase size 4 KiB,
> > total 32 MiB
> >
> > =>
> > Full flash memory erase/write/read/validate => mw 0x8060
> > 0x12348765 0x80 => sf erase 0x0 0x200
> > SF: 33554432 bytes @ 0x0 Erased: OK
> > => sf write 0x8060 0x0 0x200
> > device 0 whole chip
> > SF: 33554432 bytes @ 0x0 Written: OK
> > => sf read 0x8260 0x0 0x200
> > device 0 whole chip
> > SF: 33554432 bytes @ 0x0 Read: OK
> > => cmp.b 0x8060 0x8260 0x200 Total of 33554432 byte(s)
> > were the same
> > =>
>
> Regards,
> Bin
RE: [U-Boot Patch v1 6/7] nor: add post bfpt fix handler for is25wp256 device
Hi Vignesh,
> -Original Message-
> From: Vignesh Raghavendra
> Sent: Monday, January 27, 2020 10:48 AM
> To: Sagar Kadam ; u-boot@lists.denx.de
> Cc: Paul Walmsley ( Sifive) ;
> anup.pa...@wdc.com; atish.pa...@wdc.com; ja...@amarulasolutions.com;
> Rick Chen
> Subject: Re: [U-Boot Patch v1 6/7] nor: add post bfpt fix handler for
> is25wp256 device
>
>
>
> On 24/01/20 11:58 am, Sagar Kadam wrote:
> > Hello Vignesh,
> >
> >> -Original Message-
> >> From: Vignesh Raghavendra
> >> Sent: Friday, January 24, 2020 10:24 AM
> >> To: Sagar Kadam ; u-boot@lists.denx.de
> >> Cc: Paul Walmsley ( Sifive) ;
> >> anup.pa...@wdc.com; i...@andestech.com; atish.pa...@wdc.com;
> >> ja...@amarulasolutions.com
> >> Subject: Re: [U-Boot Patch v1 6/7] nor: add post bfpt fix handler for
> >> is25wp256 device
> >>
> >> Hi,
> >>
> >> On 24/01/20 1:46 am, Sagar Shrikant Kadam wrote:
> >>> Update vendor id for ISSI flash, enable SFDP as ISSI flash supports it
> >>> and add support for spi_nor_fixups similar to that done in linux.
> >>> Flash vendor specific fixups can be registered in spi_nor_ids, and
> >>> will be called after BFPT parsing to fix any wrong parameter read from
> >>> SFDP.
> >>>
> >>> Signed-off-by: Sagar Shrikant Kadam
> >>> ---
> >>> board/sifive/fu540/Kconfig | 1 +
> >>> drivers/mtd/spi/sf_internal.h | 16 +++
> >>> drivers/mtd/spi/spi-nor-core.c | 63
> >>> --
> >>> drivers/mtd/spi/spi-nor-ids.c | 7 -
> >>> include/linux/mtd/spi-nor.h| 1 +
> >>> 5 files changed, 85 insertions(+), 3 deletions(-)
> >>>
> >>> diff --git a/board/sifive/fu540/Kconfig b/board/sifive/fu540/Kconfig
> >>> index 75661f3..d9e4956 100644
> >>> --- a/board/sifive/fu540/Kconfig
> >>> +++ b/board/sifive/fu540/Kconfig
> >>> @@ -42,6 +42,7 @@ config BOARD_SPECIFIC_OPTIONS # dummy
> >>> imply SPI
> >>> imply SPI_SIFIVE
> >>> imply SPI_FLASH
> >>> + imply SPI_FLASH_SFDP_SUPPORT
> >>> imply SPI_FLASH_ISSI
> >>> imply MMC
> >>> imply MMC_SPI
> >>
> >> This does not belong to this patch. Its better that this change goes via
> SiFive
> >> SoC tree.
> >
> > Thanks for your inputs. I will move it.
> > Just that I understand this correctly shall I add this config change as a
> separate patch apart from the series
> > or as a different patch containing only this change within this series.
> >
>
> Unless there is a real dependency, it would be great to separate out
> SPI-NOR related changes to different series, so that it could go via
> Jagan's SPI tree.
>
> Regards
> Vignesh
>
Yes, I will exclude this patch from this series.
-BR,
Sagar
> >>
> >>> diff --git a/drivers/mtd/spi/sf_internal.h
> >>> b/drivers/mtd/spi/sf_internal.h index 5c64303..856866f 100644
> >>> --- a/drivers/mtd/spi/sf_internal.h
> >>> +++ b/drivers/mtd/spi/sf_internal.h
> >>> @@ -66,8 +66,24 @@ struct flash_info {
> >>> #define SPI_NOR_SKIP_SFDPBIT(13) /* Skip parsing of SFDP tables
> */
> >>> #define USE_CLSR BIT(14) /* use CLSR command */
> >>> #define SPI_NOR_HAS_SST26LOCKBIT(15) /* Flash supports lock/unlock
> >> via BPR */
> >>> +
> >>> +#ifdef CONFIG_SPI_FLASH_SFDP_SUPPORT
> >>
> >> Change above ifdef to:
> >>
> >>#if CONFIG_IS_ENABLED(SPI_FLASH_SFDP_SUPPORT)
> >>
> >> throughout the patch to take care of both SPL and U-Boot builds
> >>
> > Sure, will modify this and send it in V2.
> >
> >>> + /* Part specific fixup hooks */
> >>> + const struct spi_nor_fixups *fixups;
> >>> +#endif
> >>> };
> >>>
> >>> +#ifdef CONFIG_SPI_FLASH_SFDP_SUPPORT
> >>> +/*
> >>> + * Declare manufacturer specific fixup handlers that
> >>> + * can be registered as fixup's in flash info table
> >>> + * so as to update any wrong/broken SFDP parameter.
> >>> + */
> >>> +#ifdef CONFIG_SPI_FLASH_ISSI
> >>> +extern struct spi_nor_fixups is25wp256_fixups; #endif #endif
> >>> +
> >>> extern const struct flash_info spi_nor_ids[];
> >>>
> >>> #define JEDEC_MFR(info) ((info)->id[0])
RE: [U-Boot Patch v1 6/7] nor: add post bfpt fix handler for is25wp256 device
Hello Vignesh,
> -Original Message-
> From: Vignesh Raghavendra
> Sent: Friday, January 24, 2020 10:24 AM
> To: Sagar Kadam ; u-boot@lists.denx.de
> Cc: Paul Walmsley ( Sifive) ;
> anup.pa...@wdc.com; i...@andestech.com; atish.pa...@wdc.com;
> ja...@amarulasolutions.com
> Subject: Re: [U-Boot Patch v1 6/7] nor: add post bfpt fix handler for
> is25wp256 device
>
> Hi,
>
> On 24/01/20 1:46 am, Sagar Shrikant Kadam wrote:
> > Update vendor id for ISSI flash, enable SFDP as ISSI flash supports it
> > and add support for spi_nor_fixups similar to that done in linux.
> > Flash vendor specific fixups can be registered in spi_nor_ids, and
> > will be called after BFPT parsing to fix any wrong parameter read from
> > SFDP.
> >
> > Signed-off-by: Sagar Shrikant Kadam
> > ---
> > board/sifive/fu540/Kconfig | 1 +
> > drivers/mtd/spi/sf_internal.h | 16 +++
> > drivers/mtd/spi/spi-nor-core.c | 63
> > --
> > drivers/mtd/spi/spi-nor-ids.c | 7 -
> > include/linux/mtd/spi-nor.h| 1 +
> > 5 files changed, 85 insertions(+), 3 deletions(-)
> >
> > diff --git a/board/sifive/fu540/Kconfig b/board/sifive/fu540/Kconfig
> > index 75661f3..d9e4956 100644
> > --- a/board/sifive/fu540/Kconfig
> > +++ b/board/sifive/fu540/Kconfig
> > @@ -42,6 +42,7 @@ config BOARD_SPECIFIC_OPTIONS # dummy
> > imply SPI
> > imply SPI_SIFIVE
> > imply SPI_FLASH
> > + imply SPI_FLASH_SFDP_SUPPORT
> > imply SPI_FLASH_ISSI
> > imply MMC
> > imply MMC_SPI
>
> This does not belong to this patch. Its better that this change goes via
> SiFive
> SoC tree.
Thanks for your inputs. I will move it.
Just that I understand this correctly shall I add this config change as a
separate patch apart from the series
or as a different patch containing only this change within this series.
>
> > diff --git a/drivers/mtd/spi/sf_internal.h
> > b/drivers/mtd/spi/sf_internal.h index 5c64303..856866f 100644
> > --- a/drivers/mtd/spi/sf_internal.h
> > +++ b/drivers/mtd/spi/sf_internal.h
> > @@ -66,8 +66,24 @@ struct flash_info {
> > #define SPI_NOR_SKIP_SFDP BIT(13) /* Skip parsing of SFDP tables */
> > #define USE_CLSR BIT(14) /* use CLSR command */
> > #define SPI_NOR_HAS_SST26LOCK BIT(15) /* Flash supports lock/unlock
> via BPR */
> > +
> > +#ifdef CONFIG_SPI_FLASH_SFDP_SUPPORT
>
> Change above ifdef to:
>
> #if CONFIG_IS_ENABLED(SPI_FLASH_SFDP_SUPPORT)
>
> throughout the patch to take care of both SPL and U-Boot builds
>
Sure, will modify this and send it in V2.
> > + /* Part specific fixup hooks */
> > + const struct spi_nor_fixups *fixups;
> > +#endif
> > };
> >
> > +#ifdef CONFIG_SPI_FLASH_SFDP_SUPPORT
> > +/*
> > + * Declare manufacturer specific fixup handlers that
> > + * can be registered as fixup's in flash info table
> > + * so as to update any wrong/broken SFDP parameter.
> > + */
> > +#ifdef CONFIG_SPI_FLASH_ISSI
> > +extern struct spi_nor_fixups is25wp256_fixups; #endif #endif
> > +
> > extern const struct flash_info spi_nor_ids[];
> >
> > #define JEDEC_MFR(info)((info)->id[0])
> > diff --git a/drivers/mtd/spi/spi-nor-core.c
> > b/drivers/mtd/spi/spi-nor-core.c index 6e7fc23..c55116f 100644
> > --- a/drivers/mtd/spi/spi-nor-core.c
> > +++ b/drivers/mtd/spi/spi-nor-core.c
> > @@ -296,7 +296,6 @@ static void spi_nor_set_4byte_opcodes(struct
> spi_nor *nor,
> > nor->mtd.erasesize = info->sector_size;
> > break;
> >
> > - default:
>
> Is this an intentional change?
>
No this was not intentional, got reverted in 7/7
I will correct it.
> > break;
> > }
> >
> > @@ -1800,6 +1799,57 @@ static const struct sfdp_bfpt_erase
> > sfdp_bfpt_erases[] = {
> >
> > static int spi_nor_hwcaps_read2cmd(u32 hwcaps);
> >
> > +#ifdef CONFIG_SPI_FLASH_SFDP_SUPPORT
> > +/**
> > + * struct spi_nor_fixups - SPI NOR fixup hooks
> > + * @post_bfpt: called after the BFPT table has been parsed
> > + *
> > + * Those hooks can be used to tweak the SPI NOR configuration when
> > +the SFDP
> > + * table is broken or not available.
> > + */
> > +struct spi_nor_fixups {
> > + int (*post_bfpt)(struct spi_nor *nor,
> > +const struct sfdp_parameter_header *bfpt_header,
> > +const struct sfdp_bfpt *bfpt,
> > +struct spi_nor_flash_parameter *p
RE: [U-Boot Patch v1 1/7] riscv: dts: include -u-boot for dtb
Hello All, > -Original Message- > From: Sagar Kadam > Sent: Friday, January 24, 2020 1:46 AM > To: u-boot@lists.denx.de > Cc: Paul Walmsley ( Sifive) ; > anup.pa...@wdc.com; i...@andestech.com; atish.pa...@wdc.com; > ja...@amarulasolutions.com; vigne...@ti.com; Sagar Kadam > > Subject: [U-Boot Patch v1 1/7] riscv: dts: include -u-boot for dtb > > Include hifive-unleashed-a00-u-boot.dtsi introduced earlier so that it gets > compiled within the dt-blob. > Realised that this patch is not needed. Please drop this patch. Apologies for the same. Thanks, Sagar > Signed-off-by: Sagar Shrikant Kadam > --- > arch/riscv/dts/hifive-unleashed-a00.dts | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/riscv/dts/hifive-unleashed-a00.dts b/arch/riscv/dts/hifive- > unleashed-a00.dts > index 88cfcb9..89cc4be 100644 > --- a/arch/riscv/dts/hifive-unleashed-a00.dts > +++ b/arch/riscv/dts/hifive-unleashed-a00.dts > @@ -2,6 +2,7 @@ > /* Copyright (c) 2018-2019 SiFive, Inc */ > > #include "fu540-c000.dtsi" > +#include "hifive-unleashed-a00-u-boot.dtsi" > > /* Clock frequency (in Hz) of the PCB crystal for rtcclk */ > #define RTCCLK_FREQ 100 > -- > 2.7.4
RE: [U-Boot Patch v1 7/7] fu540: spi-nor: modify the flash read and program opcodes
Hello Vignesh, > -Original Message- > From: Vignesh Raghavendra > Sent: Friday, January 24, 2020 10:25 AM > To: Sagar Kadam ; u-boot@lists.denx.de > Cc: Paul Walmsley ( Sifive) ; > anup.pa...@wdc.com; i...@andestech.com; atish.pa...@wdc.com; > ja...@amarulasolutions.com > Subject: Re: [U-Boot Patch v1 7/7] fu540: spi-nor: modify the flash read and > program opcodes > > > > On 24/01/20 1:46 am, Sagar Shrikant Kadam wrote: > > This patch adds a workaround to change the read/write opcodes > > from QUAD to single bit mode. Idea here is to enable usage of > > spi-flash on the board. > > > > TODO: > > -Enable QUAD mode for spi-flash on HiFive Unleashed A00 board. > > > > Signed-off-by: Sagar Shrikant Kadam > > --- > > drivers/mtd/spi/spi-nor-core.c | 15 ++- > > 1 file changed, 14 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c > > index c55116f..35d7772 100644 > > --- a/drivers/mtd/spi/spi-nor-core.c > > +++ b/drivers/mtd/spi/spi-nor-core.c > > @@ -295,7 +295,19 @@ static void spi_nor_set_4byte_opcodes(struct > spi_nor *nor, > > nor->erase_opcode = SPINOR_OP_SE; > > nor->mtd.erasesize = info->sector_size; > > break; > > - > > +#ifdef CONFIG_TARGET_SIFIVE_FU540 > > + /* > > +* This flash device does support QUAD bit mode. But > > +* with tx-rx width specified to 4 bit mode in dt the spi > > +* driver is unable to access flash device. TODO: Once basic > > +* operational support is moved to mainline remove this > workaround. > > +*/ > > + case SNOR_MFR_ISSI: > > + nor->read_opcode = SPINOR_OP_READ_FAST; > > + nor->program_opcode = SPINOR_OP_PP; > > + break; > > +#endif > > + default: > > NACK. > > Sorry, no Target specific #if'dery hacks in spi-nor-core please. Either > debug and fix the issue or set tx-rx width to values that actually work > in the mainline. You can switch tx-rx width to 4 when TODO is actually done. > Ok, no problem. So till TODO is actually done, I will modify the existing hifive-unleashed-a00.dts present in U-Boot and submit a V2 without these work-arounds. Thanks & BR, -Sagar > > break; > > } > > > > @@ -2636,6 +2648,7 @@ int spi_nor_scan(struct spi_nor *nor) > > /* enable 4-byte addressing if the device exceeds 16MiB */ > > nor->addr_width = 4; > > if (JEDEC_MFR(info) == SNOR_MFR_SPANSION || > > + JEDEC_MFR(info) == SNOR_MFR_ISSI || > > info->flags & SPI_NOR_4B_OPCODES) > > spi_nor_set_4byte_opcodes(nor, info); > > #else > > > > -- > Regards > Vignesh
Re: [U-Boot] [PATCH v2 5/5] sifive: fu540: Enable spi-nor flash support
d is25wp256 with page size 256 Bytes, erase size 4 KiB, total > > > 32 > MiB > > > => dm tree > > > Class Index Probed DriverName > > > --- > > > root 0 [ + ] root_driver root_driver > > > simple_bus0 [ + ] generic_simple_bus|-- soc > > > clk 0 [ + ] sifive-fu540-prci | |-- > > > clock-controller@1000 > > > serial0 [ + ] serial_sifive | |-- serial@1001 > > > serial1 [ ] serial_sifive | |-- serial@10011000 > > > spi 0 [ + ] sifive_spi| |-- spi@1004 > > > spi_flash 0 [ ] spi_flash_std | | |-- flash@0 > > > spi_flash 1 [ + ] spi_flash_std | | |-- spi_flash@0:2 > > > spi_flash 2 [ + ] spi_flash_std | | |-- spi_flash@0:4 > > > spi_flash 3 [ + ] spi_flash_std | | `-- spi_flash@0:6 > > > > > > With my patch series below > > > http://patchwork.ozlabs.org/project/uboot/list/?series=129736 > > > > > > the CS number check was added to the SPI flash hence we got: > > > > > > => sf probe > > > unrecognized JEDEC id bytes: ff, ff, ff > > > Failed to initialize SPI flash at 0:0 (error -2) > > > => sf probe 2 > > > Invalid cs 2 (err=-22) > > > Invalid cs 2 (err=-22) > > > Invalid chip select 0:2 (err=-22) > > > Failed to initialize SPI flash at 0:2 (error -22) > > > => sf probe 4 > > > Invalid cs 4 (err=-22) > > > Invalid cs 4 (err=-22) > > > Invalid chip select 0:4 (err=-22) > > > Failed to initialize SPI flash at 0:4 (error -22) > > > > > > So we still need figure out why CS number 0 cannot work on SiFive. > > > > The existing quad wire that driver pushing for flash seems not > > detecting flash at CS 0 so making cr to single wire detecting flash at > > I vaguely remember someone from SiFive posted a patch that forced the > SPI controller to work under single wire mode. Maybe someone from > SiFive could help explain the weird behavior as you mentioned. > Sorry, I had not been closely looking into this thread. Yes, the initial patch posted was to add support for is25wp256 device. https://patchwork.ozlabs.org/patch/1146523/ but it seems it was bricking the board, and later couldn't follow-up on this. IIUC, spi_nor_scan has default reg_proto set to 1_1_1, and further parses slave mode and accordingly sets the hwcaps fields. Now since the device tree set's the slave mode to 4 bit mode based on the tx-bus-width, this creates a conflict due to which reg_read fails and so the sf probe fails too. Now forcing the SPI-controller in single wire mode helped the sf probe to detect the flash. Alternatively I think if we use bitlen passed by spi_mem_exec_op and prepare spi transfer's in controller based on max of t->rx_nbits, t->tx_nbits as done in linux driver this should work. Any thoughts on this? Thanks & BR, Sagar Kadam > > CS0. One more point is that flash seems available in different CS, not > > sure whether the hardware wired this logic or it has flash really on > > those CS's. > > > > => sf probe 0:0 > > SF: Detected is25wp256 with page size 256 Bytes, erase size 4 KiB, total 32 > MiB > > => sf probe 0:1 > > unrecognized JEDEC id bytes: ff, ff, ff > > Failed to initialize SPI flash at 0:1 (error -2) > > => sf probe 0:2 > > SF: Detected is25wp256 with page size 256 Bytes, erase size 4 KiB, total 32 > MiB > > => sf probe 0:3 > > unrecognized JEDEC id bytes: ff, ff, ff > > Failed to initialize SPI flash at 0:3 (error -2) > > => sf probe 0:4 > > SF: Detected is25wp256 with page size 256 Bytes, erase size 4 KiB, total 32 > MiB > > => sf probe 0:5 > > unrecognized JEDEC id bytes: ff, ff, ff > > Failed to initialize SPI flash at 0:5 (error -2) > > => sf probe 0:6 > > SF: Detected is25wp256 with page size 256 Bytes, erase size 4 KiB, total 32 > MiB > > => sf probe 0:7 > > unrecognized JEDEC id bytes: ff, ff, ff > > Failed to initialize SPI flash at 0:7 (error -2) > > => sf probe 0:8 > > SF: Detected is25wp256 with page size 256 Bytes, erase size 4 KiB, total 32 > MiB > > => sf probe 0:9 > > unrecognized JEDEC id bytes: ff, ff, ff > > Failed to initialize SPI flash at 0:9 (error -2) > > Regards, > Bin > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-BOOT PATCH v2 1/2] gpio: sifive: add support for DM based gpio driver for FU540-SoC
UTPUT_EN) & BIT(offset);
> > + indir = readl(plat->base + GPIO_INPUT_EN) & BIT(offset);
> > +
> > + if (outdir)
> > + /* Pin at specified offset is configured as output */
> > + val = GPIOF_OUTPUT;
> > + else if (indir)
> > + /* Pin at specified offset is configured as input */
> > + val = GPIOF_INPUT;
> > + else
> > + /*The requested GPIO is not set as input or output */
>
> nits: need a space after /*
>
> > + val = GPIOF_UNUSED;
> > +
> > + return val;
> > +}
> > +
> > +static const struct udevice_id sifive_gpio_match[] = {
> > + { .compatible = "sifive,gpio0" },
> > + { }
> > +};
> > +
> > +static const struct dm_gpio_ops sifive_gpio_ops = {
> > + .direction_input= sifive_gpio_direction_input,
> > + .direction_output = sifive_gpio_direction_output,
> > + .get_value = sifive_gpio_get_value,
> > + .set_value = sifive_gpio_set_value,
> > + .get_function = sifive_gpio_get_function,
> > +};
> > +
> > +static int sifive_gpio_ofdata_to_platdata(struct udevice *dev)
> > +{
> > + struct sifive_gpio_platdata *plat = dev_get_platdata(dev);
> > + fdt_addr_t addr;
> > +
> > + addr = devfdt_get_addr(dev);
> > + if (addr == FDT_ADDR_T_NONE)
> > + return -EINVAL;
> > +
> > + plat->base = (void *)addr;
> > + return 0;
> > +}
> > +
> > +U_BOOT_DRIVER(gpio_sifive) = {
> > + .name = "gpio_sifive",
> > + .id = UCLASS_GPIO,
> > + .of_match = sifive_gpio_match,
> > + .ofdata_to_platdata = of_match_ptr(sifive_gpio_ofdata_to_platdata),
> > + .platdata_auto_alloc_size = sizeof(struct sifive_gpio_platdata),
> > + .ops= _gpio_ops,
> > + .probe = sifive_gpio_probe,
> > +};
> > --
>
> Other than above,
>
> Reviewed-by: Bin Meng
Thanks for the review !!
BR,
Sagar Kadam
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-BOOT PATCH v1 0/2] add gpio support for HiFive Unleashed A00 board.
Hi Bin, On Thu, Sep 26, 2019 at 7:26 AM Bin Meng wrote: > > Hi Sagar, > > On Thu, Sep 26, 2019 at 1:54 AM Sagar Kadam wrote: > > > > Hi Bin, > > > > On Wed, Sep 18, 2019 at 1:23 PM Bin Meng wrote: > > > > > > Hi Sagar, > > > > > > On Tue, Sep 10, 2019 at 11:44 PM Sagar Shrikant Kadam > > > wrote: > > > > > > > > U-Boot currently is missing GPIO support for FU540-C000 SoC which is > > > > mounted on HiFive Unleashed A00 board. This patch is intended to add DM > > > > based GPIO controller driver in order to access GPIO pins within the SoC > > > > using GPIO command in U-Boot. More details on the GPIO controller within > > > > the SoC can be found at[1] > > > > > > > > The driver is based above master branch of u-boot-riscv.git and > > > > provides a > > > > method to configure Input/Output mode of the GPIO pin along with an > > > > option > > > > to set or clear state of the GPIO pin. The patch is available in > > > > dev/sagark/gpio_v3 branch here[2]. > > > > > > > > GPIO device node added to the mainline bound device tree for HiFive > > > > Unleashed is available in dev/sagark/mlv5.3-rc5 branch of repo here[3]. > > > > > > > > This implementation is ported from linux driver submitted for review > > > > at [4]. > > > > > > > > More details of GPIO pin routing on J1 header is available in schematic > > > > document[5] > > > > > > > > [1] https://static.dev.sifive.com/FU540-C000-v1.0.pdf > > > > [2] https://github.com/sagsifive/u-boot > > > > [3] https://github.com/sagsifive/riscv-linux-hifive/ > > > > [4] https://lkml.org/lkml/2018/10/9/1103 > > > > [5] > > > > https://static.dev.sifive.com/dev-kits/hifive-unleashed/hifive-unleashed-a00-schematics.pdf > > > > > > > > Driver Testing: > > > > #Set GPIO1 high. > > > > =>gpio set 1 > > > > Can be confirmed by probing pin No #24 on J1 Header or memory dump of > > > > gpio register space viz: #md 0x1006 > > > > > > > > #Set GPIO1 low > > > > =>gpio clear 0 > > > > > > > > #Toggle GPIO1 > > > > =>gpio toggle 1 #Toggle value of GPIO1 > > > > =>gpio toggle 1 #Toggle value of GPIO1 > > > > > > > > #Configure pin as input > > > > =>gpio input 3 #Configure gpio line 3 as input. > > > > > > > > #Error check > > > > =>gpio set 16 #Not a valid GPIO number for FU540-C000 > > > > GPIO: '16' not found > > > > Command 'gpio' failed: Error -22 > > > > > > > > > > I tested this: > > > > > > => gpio status -a > > > Bank gpio@1006: > > > gpio@10060: unknown > > > gpio@10061: unknown > > > gpio@10062: unknown > > > gpio@10063: unknown > > > gpio@10064: unknown > > > gpio@10065: unknown > > > gpio@10066: unknown > > > gpio@10067: unknown > > > gpio@10068: unknown > > > gpio@10069: unknown > > > gpio@100610: unknown > > > gpio@100611: unknown > > > gpio@100612: unknown > > > gpio@100613: unknown > > > gpio@100614: unknown > > > gpio@100615: unknown > > > > > > The status is "unknown" for all gpio pins, which is wrong. It should > > > be either input or output. > > > > Thank you for your suggestions. > > The get_function operation is missing for this driver and so the > > status is unknown. > > I will implement it and send a revised version. Thanks for catching this. > > Please correct me if I am wrong, what I do see is that the gpio command > > uses the bank name appended before the GPIO number. So the bank_name > > as assigned in the driver probe function gets prefixed to the pin number and > > so it shows: > > gpio@10060 > > gpio@10061 > > and so on. > > I see that few driver's updates the uc_priv->bank_name in probe function > > with '_' as the separator between bank_name and pin number and so > > #gpio status -a will show it as : > > > > Bank : > > _0: input : 1 [] > > _1: input : 1 [] > > and so on > > > > eg: In the current case here it will show as > > Bank gpio@1006_: > > gpio@1006_0 > > gpio@1006_1 and so on. > > > > Please let me know if this implementation is ok. > > > > > > Also the gpio pin name is weird. I think we should use "0, 1, 2 ..." > > > > > The current implementation of the gpio_get_status function includes > > the base_name > > to the pin description. Truncating it here can help to get pin numbers > > as just numbers > > "0,1,2". I will also include this if needed? > > > > I think _0 is fine. Thanks! > Thanks, I will roll out the next patch with necessary changes. BR, Sagar > Regards, > Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-BOOT PATCH v1 1/2] gpio: fu540: add support for DM based gpio driver for FU540-SoC
Hi Bin,
On Wed, Sep 18, 2019 at 3:09 PM Bin Meng wrote:
>
> Hi Sagar,
>
> On Tue, Sep 10, 2019 at 11:44 PM Sagar Shrikant Kadam
> wrote:
> >
> > This patch adds a DM based driver model for gpio controller present in
> > FU540-C000 SoC on HiFive Unleashed A00 board. This SoC has one GPIO
> > bank and 16 GPIO lines in total, out of which GPIO0 to GPIO9 and
> > GPIO15 are routed to the J1 header on the board.
> >
> > This implementation is ported from linux based gpio driver submitted
> > for review by Wesley W. Terpstra and/or Atish Patra
> > (many thanks !!). The linux driver can be referred
> > here [1]
> >
> > [1]: https://lkml.org/lkml/2018/10/9/1103
> >
> > Signed-off-by: Sagar Shrikant Kadam
> > ---
> > arch/riscv/include/asm/arch-generic/gpio.h | 35 +++
> > arch/riscv/include/asm/gpio.h | 6 ++
> > drivers/gpio/Kconfig | 8 ++
> > drivers/gpio/Makefile | 1 +
> > drivers/gpio/sifive-gpio.c | 143
> > +
> > 5 files changed, 193 insertions(+)
> > create mode 100644 arch/riscv/include/asm/arch-generic/gpio.h
> > create mode 100644 arch/riscv/include/asm/gpio.h
> > create mode 100644 drivers/gpio/sifive-gpio.c
> >
> > diff --git a/arch/riscv/include/asm/arch-generic/gpio.h
> > b/arch/riscv/include/asm/arch-generic/gpio.h
> > new file mode 100644
> > index 000..7287298
> > --- /dev/null
> > +++ b/arch/riscv/include/asm/arch-generic/gpio.h
> > @@ -0,0 +1,35 @@
> > +/* SPDX-License-Identifier: GPL-2.0+ */
> > +/*
> > + * Copyright (C) 2019 SiFive, Inc.
> > + */
> > +
> > +#ifndef _GPIO_FU540_H
>
> _GPIO_SIFIVE_H
>
> > +#define _GPIO_FU540_H
> > +
> > +#define GPIO_INPUT_VAL 0x00
> > +#define GPIO_INPUT_EN 0x04
> > +#define GPIO_OUTPUT_EN 0x08
> > +#define GPIO_OUTPUT_VAL0x0C
> > +#define GPIO_RISE_IE 0x18
> > +#define GPIO_RISE_IP 0x1C
> > +#define GPIO_FALL_IE 0x20
> > +#define GPIO_FALL_IP 0x24
> > +#define GPIO_HIGH_IE 0x28
> > +#define GPIO_HIGH_IP 0x2C
> > +#define GPIO_LOW_IE0x30
> > +#define GPIO_LOW_IP0x34
> > +#define GPIO_OUTPUT_XOR0x40
> > +
> > +#define NR_GPIOS 16
> > +
> > +enum gpio_state {
> > + LOW,
> > + HIGH
> > +};
> > +
> > +/* Details about a GPIO bank */
> > +struct fu540_gpio_platdata {
>
> sifive_gpio_platdata
>
Ok.
> > + void *base; /* address of registers in physical memory */
> > +};
> > +
> > +#endif /* _GPIO_FU540_H */
> > diff --git a/arch/riscv/include/asm/gpio.h b/arch/riscv/include/asm/gpio.h
> > new file mode 100644
> > index 000..008d756
> > --- /dev/null
> > +++ b/arch/riscv/include/asm/gpio.h
> > @@ -0,0 +1,6 @@
> > +/* SPDX-License-Identifier: GPL-2.0+ */
> > +/*
> > + * Copyright 2018 SiFive, Inc.
> > + */
> > +
> > +#include
> > diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> > index f2dabb5..ec48f26 100644
> > --- a/drivers/gpio/Kconfig
> > +++ b/drivers/gpio/Kconfig
> > @@ -285,6 +285,14 @@ config STM32_GPIO
> > usable on many stm32 families like stm32f4/f7/h7 and stm32mp1.
> > Tested on STM32F7.
> >
> > +config SIFIVE_GPIO
> > + bool "SiFive FU540 GPIO driver"
>
> just "SiFive GPIO driver"?
>
Ok. Will exclude FU540 from above.
> > + depends on DM_GPIO
> > + help
> > + Device model driver for GPIO controller present in FU540 SoC. This
>
> present in SiFive FU540 SoC
>
> > + driver enables GPIO interface on HiFive Unleashed A00 board a
> > board
>
> remove "a board"
OK.
>
> > + from SiFive Inc. having FU540-C000 SoC.
>
> remove this line
>
Ok
> > +
> > config MVEBU_GPIO
> > bool "Marvell MVEBU GPIO driver"
> > depends on DM_GPIO && ARCH_MVEBU
> > diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
> > index 4a8aa0f..ccc49e2 100644
> > --- a/drivers/gpio/Makefile
> > +++ b/drivers/gpio/Makefile
> > @@ -61,3 +61,4 @@ obj-$(CONFIG_$(SPL_)PCF8575_GPIO) += pcf8575_gpio.o
> > obj-$(CONFIG_PM8916_GPIO) += pm8916_gpio.o
> > obj-$(CONFIG_MT7621_GPIO) += mt7621_gpio.o
> > obj-$(CONFIG_MSCC_SGPIO) += mscc_sgpio.o
> > +obj-$(CONFIG_SIFIVE_GPIO) += sifive-gpio.o
>
Re: [U-Boot] [U-BOOT PATCH v1 0/2] add gpio support for HiFive Unleashed A00 board.
Hi Bin, On Wed, Sep 18, 2019 at 1:23 PM Bin Meng wrote: > > Hi Sagar, > > On Tue, Sep 10, 2019 at 11:44 PM Sagar Shrikant Kadam > wrote: > > > > U-Boot currently is missing GPIO support for FU540-C000 SoC which is > > mounted on HiFive Unleashed A00 board. This patch is intended to add DM > > based GPIO controller driver in order to access GPIO pins within the SoC > > using GPIO command in U-Boot. More details on the GPIO controller within > > the SoC can be found at[1] > > > > The driver is based above master branch of u-boot-riscv.git and provides a > > method to configure Input/Output mode of the GPIO pin along with an option > > to set or clear state of the GPIO pin. The patch is available in > > dev/sagark/gpio_v3 branch here[2]. > > > > GPIO device node added to the mainline bound device tree for HiFive > > Unleashed is available in dev/sagark/mlv5.3-rc5 branch of repo here[3]. > > > > This implementation is ported from linux driver submitted for review > > at [4]. > > > > More details of GPIO pin routing on J1 header is available in schematic > > document[5] > > > > [1] https://static.dev.sifive.com/FU540-C000-v1.0.pdf > > [2] https://github.com/sagsifive/u-boot > > [3] https://github.com/sagsifive/riscv-linux-hifive/ > > [4] https://lkml.org/lkml/2018/10/9/1103 > > [5] > > https://static.dev.sifive.com/dev-kits/hifive-unleashed/hifive-unleashed-a00-schematics.pdf > > > > Driver Testing: > > #Set GPIO1 high. > > =>gpio set 1 > > Can be confirmed by probing pin No #24 on J1 Header or memory dump of > > gpio register space viz: #md 0x1006 > > > > #Set GPIO1 low > > =>gpio clear 0 > > > > #Toggle GPIO1 > > =>gpio toggle 1 #Toggle value of GPIO1 > > =>gpio toggle 1 #Toggle value of GPIO1 > > > > #Configure pin as input > > =>gpio input 3 #Configure gpio line 3 as input. > > > > #Error check > > =>gpio set 16 #Not a valid GPIO number for FU540-C000 > > GPIO: '16' not found > > Command 'gpio' failed: Error -22 > > > > I tested this: > > => gpio status -a > Bank gpio@1006: > gpio@10060: unknown > gpio@10061: unknown > gpio@10062: unknown > gpio@10063: unknown > gpio@10064: unknown > gpio@10065: unknown > gpio@10066: unknown > gpio@10067: unknown > gpio@10068: unknown > gpio@10069: unknown > gpio@100610: unknown > gpio@100611: unknown > gpio@100612: unknown > gpio@100613: unknown > gpio@100614: unknown > gpio@100615: unknown > > The status is "unknown" for all gpio pins, which is wrong. It should > be either input or output. Thank you for your suggestions. The get_function operation is missing for this driver and so the status is unknown. I will implement it and send a revised version. Thanks for catching this. Please correct me if I am wrong, what I do see is that the gpio command uses the bank name appended before the GPIO number. So the bank_name as assigned in the driver probe function gets prefixed to the pin number and so it shows: gpio@10060 gpio@10061 and so on. I see that few driver's updates the uc_priv->bank_name in probe function with '_' as the separator between bank_name and pin number and so #gpio status -a will show it as : Bank : _0: input : 1 [] _1: input : 1 [] and so on eg: In the current case here it will show as Bank gpio@10060000_: gpio@1006_0 gpio@1006_1 and so on. Please let me know if this implementation is ok. > > Also the gpio pin name is weird. I think we should use "0, 1, 2 ..." > The current implementation of the gpio_get_status function includes the base_name to the pin description. Truncating it here can help to get pin numbers as just numbers "0,1,2". I will also include this if needed? Thanks & BR, Sagar Kadam > Regards, > Bin > > Regards, > Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-BOOT PATCH 0/3] add support for spi-nor device on HiFive Unleashed board
Hello Bin, On Tue, Aug 27, 2019 at 3:48 AM Bin Meng wrote: > > On Wed, Aug 14, 2019 at 1:08 AM Sagar Shrikant Kadam > wrote: > > > > This patch series adds support for 32MiB SPI-NOR flash (is25wp256 from > > ISSI). Many thanks to Bhargav Shah for > > porting the spi-nor patches from linux to U-boot in order to support > > this device. > > Ref: linux patches which are under review > > https://lkml.org/lkml/2019/7/2/859 > > > > Linux has an option of registering post-bfpt fixups in order to over-ride > > the incorrect configuration of flash devices due to wrong SFDP entries read > > from the flash device during nor scan phase. The 1st patch introduces this > > support to register post bfpt fixup hook similar to that done in linux. > > > > The second patch in the series enables support for the flash device in > > single I/O mode. A post bfpt fixup is registered because the flash device > > gets BFPT_DWORD1_ADDRESS_BYTES_3_ONLY from BFPT table for address width, > > whereas the flash can support 4 byte address width. > > The SPI_NOR_HAS_BP3 bit indicates that the flash protection block has BP0 > > to BP3 bits. > > > > Lock/Unlock mechanism: > > The implementation is based on stm_lock/unlock scheme and is validated for > > different number of blocks passed to sf command. Unlock scheme unilateraly > > clears all the protection bits of all blocks in the status register. > > > > The series is based on the master branch of[1] > > [1] https://gitlab.denx.de/u-boot/custodians/u-boot-riscv > > > > and is available in dev/sagark/hifive-spi-nor_v2 branch of[2] > > [2] https://github.com/sagsifive/u-boot. > > > > Flash operations like erase/read/write lock/unlock are verified and > > data integrity is checked using sf commands as follows: > > > > => sf write 0x8060 0x0 0x200 > > device 0 whole chip > > SF: 33554432 bytes @ 0x0 Written: OK > > => sf read 0x8270 0x0 0x200 > > device 0 whole chip > > SF: 33554432 bytes @ 0x0 Read: OK > > => cmp.b 0x8060 0x8270 0x200 > > Total of 33554432 byte(s) were the same > > > > => sf protect lock 0x100 0x100 > > => mw 0x8060 0x12345678 0x200 > > => sf write 0x8060 0x0 0x200 > >Reset the board to flush out data from memory > > => sf probe > > => sf read 0x8060 0x0 0x200 > >In memory dump after sf read from address 0x8060 we can see that > >upper 16MiB flash section is protected. > > > > > > Sagar Shrikant Kadam (3): > > spi: nor: add spi-nor-fixup handlers for nor devices > > spi: nor: add support for is25wp256 > > spi: riscv: use single bit mode for spi transfers > > > > board/sifive/fu540/Kconfig | 5 + > > drivers/mtd/spi/sf_internal.h | 23 +++ > > drivers/mtd/spi/spi-nor-core.c | 373 > > +++-- > > drivers/mtd/spi/spi-nor-ids.c | 5 + > > drivers/spi/spi-sifive.c | 7 +- > > include/linux/mtd/spi-nor.h| 8 + > > 6 files changed, 363 insertions(+), 58 deletions(-) > > > > -- > > Warning! This patch series will brick the HiFive Unleashed board. > > What I did was only: > => sf probe > > everything looks good as long as you don't power off the board. > > But when you power off the board and power on, there is no console > output anymore. > Does disconnecting and connecting back the terminal emulator work here? > I then re-flashed the board using SD card rescue image, and confirmed > that this single "sf probe" command will brick the board (once again!) > I would like to understand the situation here can you please elaborate it, so that I can reproduce it at my end. What is the boot mode you are using to test these patches? Are you loading fsbl and U-boot from Flash or from SD Card? Thanks & BR, Sagar Kadam > Regards, > Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-BOOT PATCH] gpio: fu540: add support for DM based gpio driver for FU540 SoC
as output. */
>
> nits: remove the ending period
Ok, will do.
>
> > + fu540_update_gpio_reg(plat->base + GPIO_OUTPUT_EN, offset, true);
> > + fu540_update_gpio_reg(plat->base + GPIO_INPUT_EN, offset, false);
> > +
> > + /* Set the Output state of the PIN */
> > + fu540_update_gpio_reg(plat->base + GPIO_OUTPUT_VAL, offset, value);
> > +
> > + return 0;
> > +}
> > +
> > +static int fu540_gpio_get_value(struct udevice *dev, u32 offset)
> > +{
> > + struct fu540_gpio_platdata *plat = dev_get_platdata(dev);
> > + int val;
> > + int dir;
> > +
> > + if (offset > NR_GPIOS)
> > + return -EINVAL;
> > +
> > + /* Get direction of the pin OUTPUT=0 INPUT=1 */
> > + dir = !(readl(plat->base + GPIO_OUTPUT_EN) & BIT(offset));
> > +
> > + if (dir)
> > + val = readl(plat->base + GPIO_INPUT_VAL) & BIT(offset);
> > + else
> > + val = readl(plat->base + GPIO_OUTPUT_VAL) & BIT(offset);
> > +
> > + return val ? HIGH : LOW;
> > +}
> > +
> > +static int fu540_gpio_set_value(struct udevice *dev, u32 offset, int value)
> > +{
> > + struct fu540_gpio_platdata *plat = dev_get_platdata(dev);
> > +
> > + if (offset > NR_GPIOS)
> > + return -EINVAL;
> > +
> > + fu540_update_gpio_reg(plat->base + GPIO_OUTPUT_VAL, offset, value);
> > +
> > + return 0;
> > +}
> > +
> > +static const struct udevice_id fu540_gpio_match[] = {
> > + { .compatible = "sifive,gpio0" },
> > + { }
> > +};
> > +
> > +static const struct dm_gpio_ops gpio_sifive_ops = {
> > + .direction_input= fu540_gpio_direction_input,
> > + .direction_output = fu540_gpio_direction_output,
> > + .get_value = fu540_gpio_get_value,
> > + .set_value = fu540_gpio_set_value,
> > +};
> > +
> > +static int fu540_gpio_ofdata_to_platdata(struct udevice *dev)
> > +{
> > + struct fu540_gpio_platdata *plat = dev_get_platdata(dev);
> > + fdt_addr_t addr;
> > +
> > + addr = devfdt_get_addr(dev);
> > + if (addr == FDT_ADDR_T_NONE)
> > + return -EINVAL;
> > +
> > + plat->base = (u8 *)addr;
> > + return 0;
> > +}
> > +
> > +U_BOOT_DRIVER(gpio_sifive) = {
> > + .name = "gpio_sifive",
> > + .id = UCLASS_GPIO,
> > + .of_match = fu540_gpio_match,
> > + .ofdata_to_platdata = of_match_ptr(fu540_gpio_ofdata_to_platdata),
> > + .platdata_auto_alloc_size = sizeof(struct fu540_gpio_platdata),
> > + .ops= _sifive_ops,
> > + .probe = fu540_gpio_probe,
> > + .priv_auto_alloc_size = sizeof(struct fu540_gpio_platdata),
>
> This priv_auto_alloc_size is not used anywhere in this driver.
>
Yes, the current implementation used the platform data for accessing
the gpio registers. I will update the driver to use the devices private space
allocated by priv_auto_alloc_size
Thanks & BR,
Sagar Kadam
> Regards,
> Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-BOOT PATCH v1] riscv: sifive: fu540: set serial environment variable from otp
Hi Bin, On Mon, Aug 12, 2019 at 8:43 PM Bin Meng wrote: > > On Mon, Aug 12, 2019 at 10:58 PM Sagar Shrikant Kadam > wrote: > > > > This patch sets the serial# environment variable by reading the > > board serial number from the OTP memory region. > > > > Signed-off-by: Sagar Shrikant Kadam > > Reviewed-by: Anup Patel > > --- > > board/sifive/fu540/fu540.c | 18 ++ > > 1 file changed, 14 insertions(+), 4 deletions(-) > > > > Reviewed-by: Bin Meng > Tested-by: Bin Meng Thanks for Reviewing and Testing the patch. Regards, Sagar ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-BOOT PATCH] riscv: sifive: fu540: set serial environment variable from otp
Hi Bin,
On Mon, Aug 12, 2019 at 2:34 PM Bin Meng wrote:
>
> On Mon, Aug 12, 2019 at 2:42 PM Sagar Shrikant Kadam
> wrote:
> >
> > This patch sets the serial# environment variable by reading the
> > board serial number from the OTP memory region.
> >
> > Signed-off-by: Sagar Shrikant Kadam
> > ---
> > board/sifive/fu540/fu540.c | 18 ++
> > 1 file changed, 14 insertions(+), 4 deletions(-)
> >
> > diff --git a/board/sifive/fu540/fu540.c b/board/sifive/fu540/fu540.c
> > index 11daf1a..06bf442 100644
> > --- a/board/sifive/fu540/fu540.c
> > +++ b/board/sifive/fu540/fu540.c
> > @@ -122,10 +122,20 @@ static void fu540_setup_macaddr(u32 serialnum)
> >
> > int misc_init_r(void)
> > {
> > - /* Set ethaddr environment variable if not set */
> > - if (!env_get("ethaddr"))
> > - fu540_setup_macaddr(fu540_read_serialnum());
> > -
> > + u32 serial_num;
> > + char buf[11] = {0};
>
> buf[9] should be enough.
>
> > +
> > + /* Set ethaddr environment variable from board serial number */
> > + if (!env_get("serial#")) {
> > + serial_num = fu540_read_serialnum();
> > + if (!serial_num) {
> > + WARN(1, "Board serial number should not be 0 !!");
>
> nits: please use true instead of 1, and adding a '\n' at the end.
>
Thanks for your suggestions, I will incorporate these in the next
version of this patch.
BR,
Sagar Kadam
> > + return 0;
> > + }
> > + snprintf(buf, sizeof(buf), "%08x", serial_num);
> > + env_set("serial#", buf);
> > + fu540_setup_macaddr(serial_num);
> > + }
> > return 0;
> > }
>
> Regards,
> Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-BOOT PATCH] riscv: sifive: fu540: set serial environment variable from otp
Hi Anup,
On Mon, Aug 12, 2019 at 1:00 PM Anup Patel wrote:
>
> On Mon, Aug 12, 2019 at 12:12 PM Sagar Shrikant Kadam
> wrote:
> >
> > This patch sets the serial# environment variable by reading the
> > board serial number from the OTP memory region.
> >
> > Signed-off-by: Sagar Shrikant Kadam
> > ---
> > board/sifive/fu540/fu540.c | 18 ++
> > 1 file changed, 14 insertions(+), 4 deletions(-)
> >
> > diff --git a/board/sifive/fu540/fu540.c b/board/sifive/fu540/fu540.c
> > index 11daf1a..06bf442 100644
> > --- a/board/sifive/fu540/fu540.c
> > +++ b/board/sifive/fu540/fu540.c
> > @@ -122,10 +122,20 @@ static void fu540_setup_macaddr(u32 serialnum)
> >
> > int misc_init_r(void)
> > {
> > - /* Set ethaddr environment variable if not set */
> > - if (!env_get("ethaddr"))
> > - fu540_setup_macaddr(fu540_read_serialnum());
> > -
> > + u32 serial_num;
> > + char buf[11] = {0};
> > +
> > + /* Set ethaddr environment variable from board serial number */
> > + if (!env_get("serial#")) {
> > + serial_num = fu540_read_serialnum();
> > + if (!serial_num) {
> > + WARN(1, "Board serial number should not be 0 !!");
> > + return 0;
> > + }
> > + snprintf(buf, sizeof(buf), "%08x", serial_num);
> > + env_set("serial#", buf);
> > + fu540_setup_macaddr(serial_num);
> > + }
> > return 0;
> > }
> >
> > --
> > 2.7.4
> >
> > ___
> > U-Boot mailing list
> > U-Boot@lists.denx.de
> > https://lists.denx.de/listinfo/u-boot
>
> Looks good to me.
>
> Reviewed-by: Anup Patel
>
Thanks for the review.
BR,
Sagar
> Regards,
> Anup
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] sifive: riscv: update Hifive Unleashed configuration infrastructure
Hi Anup, On Thu, Aug 1, 2019 at 9:26 PM Anup Patel wrote: > > On Thu, Aug 1, 2019 at 8:26 PM Sagar Kadam wrote: > > > > Hi Anup, > > > > On Wed, Jul 31, 2019 at 1:50 PM Anup Patel wrote: > > > > > > On Tue, Jul 30, 2019 at 11:01 PM Sagar Kadam > > > wrote: > > > > > > > > Hello Anup, > > > > > > > > On Tue, Jul 30, 2019 at 9:12 AM Anup Patel wrote: > > > > > > > > > > On Mon, Jul 29, 2019 at 6:13 PM Sagar Shrikant Kadam > > > > > wrote: > > > > > > > > > > > > This patch aligns the current implementation of HiFive Unleashed > > > > > > board configuration framework with the one described in > > > > > > doc/README.kconfig. > > > > > > > > > > > > Signed-off-by: Sagar Shrikant Kadam > > > > > > --- > > > > > > arch/riscv/Kconfig | 6 +- > > > > > > arch/riscv/cpu/generic/Kconfig | 12 --- > > > > > > arch/riscv/cpu/generic/Makefile | 6 -- > > > > > > arch/riscv/cpu/generic/cpu.c | 35 --- > > > > > > arch/riscv/cpu/generic/dram.c| 37 --- > > > > > > arch/riscv/cpu/u54-mc/Kconfig| 12 +++ > > > > > > arch/riscv/cpu/u54-mc/Makefile | 6 ++ > > > > > > arch/riscv/cpu/u54-mc/cpu.c | 35 +++ > > > > > > arch/riscv/cpu/u54-mc/dram.c | 37 +++ > > > > > > arch/riscv/include/asm/arch-fu540-c000/clk.h | 14 +++ > > > > > > arch/riscv/include/asm/arch-generic/clk.h| 14 --- > > > > > > board/sifive/fu540/Kconfig | 49 -- > > > > > > board/sifive/fu540/MAINTAINERS | 9 -- > > > > > > board/sifive/fu540/Makefile | 5 - > > > > > > board/sifive/fu540/fu540.c | 139 > > > > > > --- > > > > > > board/sifive/hifive_unleashed/Kconfig| 52 ++ > > > > > > board/sifive/hifive_unleashed/MAINTAINERS| 9 ++ > > > > > > board/sifive/hifive_unleashed/Makefile | 5 + > > > > > > board/sifive/hifive_unleashed/fu540.c| 139 > > > > > > +++ > > > > > > configs/hifive_unleashed_defconfig | 11 +++ > > > > > > configs/sifive_fu540_defconfig | 11 --- > > > > > > include/configs/hifive_unleashed.h | 47 + > > > > > > include/configs/sifive-fu540.h | 47 - > > > > > > 23 files changed, 370 insertions(+), 367 deletions(-) > > > > > > delete mode 100644 arch/riscv/cpu/generic/Kconfig > > > > > > delete mode 100644 arch/riscv/cpu/generic/Makefile > > > > > > delete mode 100644 arch/riscv/cpu/generic/cpu.c > > > > > > delete mode 100644 arch/riscv/cpu/generic/dram.c > > > > > > create mode 100644 arch/riscv/cpu/u54-mc/Kconfig > > > > > > create mode 100644 arch/riscv/cpu/u54-mc/Makefile > > > > > > create mode 100644 arch/riscv/cpu/u54-mc/cpu.c > > > > > > create mode 100644 arch/riscv/cpu/u54-mc/dram.c > > > > > > create mode 100644 arch/riscv/include/asm/arch-fu540-c000/clk.h > > > > > > delete mode 100644 arch/riscv/include/asm/arch-generic/clk.h > > > > > > delete mode 100644 board/sifive/fu540/Kconfig > > > > > > delete mode 100644 board/sifive/fu540/MAINTAINERS > > > > > > delete mode 100644 board/sifive/fu540/Makefile > > > > > > delete mode 100644 board/sifive/fu540/fu540.c > > > > > > create mode 100644 board/sifive/hifive_unleashed/Kconfig > > > > > > create mode 100644 board/sifive/hifive_unleashed/MAINTAINERS > > > > > > create mode 100644 board/sifive/hifive_unleashed/Makefile > > > > > > create mode 100644 board/sifive/hifive_unleashed/fu540.c > > > > > > create mode 100644 configs/hifive_unleashed_defconfig > > > > > > delete mode 100644 configs/sifive_fu540_defconfig > > > > > > create mode 100644 include/configs/hifive_unleashed.h > > > > > > delete mode 100644 i
Re: [U-Boot] [PATCH] sifive: riscv: update Hifive Unleashed configuration infrastructure
Hi Andreas, On Wed, Jul 31, 2019 at 2:02 PM Andreas Schwab wrote: > > On Jul 30 2019, Sagar Kadam wrote: > > > I do remember using "git mv" here. > > git mv is identical to git rm + git add. A git repository has no > concept of file renames. > > Andreas. > Thanks, for clarifying. Regards, Sagar Kadam > -- > Andreas Schwab, SUSE Labs, sch...@suse.de > GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 > "And now for something completely different." ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] sifive: riscv: update Hifive Unleashed configuration infrastructure
Hi Anup, On Wed, Jul 31, 2019 at 1:50 PM Anup Patel wrote: > > On Tue, Jul 30, 2019 at 11:01 PM Sagar Kadam wrote: > > > > Hello Anup, > > > > On Tue, Jul 30, 2019 at 9:12 AM Anup Patel wrote: > > > > > > On Mon, Jul 29, 2019 at 6:13 PM Sagar Shrikant Kadam > > > wrote: > > > > > > > > This patch aligns the current implementation of HiFive Unleashed > > > > board configuration framework with the one described in > > > > doc/README.kconfig. > > > > > > > > Signed-off-by: Sagar Shrikant Kadam > > > > --- > > > > arch/riscv/Kconfig | 6 +- > > > > arch/riscv/cpu/generic/Kconfig | 12 --- > > > > arch/riscv/cpu/generic/Makefile | 6 -- > > > > arch/riscv/cpu/generic/cpu.c | 35 --- > > > > arch/riscv/cpu/generic/dram.c| 37 --- > > > > arch/riscv/cpu/u54-mc/Kconfig| 12 +++ > > > > arch/riscv/cpu/u54-mc/Makefile | 6 ++ > > > > arch/riscv/cpu/u54-mc/cpu.c | 35 +++ > > > > arch/riscv/cpu/u54-mc/dram.c | 37 +++ > > > > arch/riscv/include/asm/arch-fu540-c000/clk.h | 14 +++ > > > > arch/riscv/include/asm/arch-generic/clk.h| 14 --- > > > > board/sifive/fu540/Kconfig | 49 -- > > > > board/sifive/fu540/MAINTAINERS | 9 -- > > > > board/sifive/fu540/Makefile | 5 - > > > > board/sifive/fu540/fu540.c | 139 > > > > --- > > > > board/sifive/hifive_unleashed/Kconfig| 52 ++ > > > > board/sifive/hifive_unleashed/MAINTAINERS| 9 ++ > > > > board/sifive/hifive_unleashed/Makefile | 5 + > > > > board/sifive/hifive_unleashed/fu540.c| 139 > > > > +++ > > > > configs/hifive_unleashed_defconfig | 11 +++ > > > > configs/sifive_fu540_defconfig | 11 --- > > > > include/configs/hifive_unleashed.h | 47 + > > > > include/configs/sifive-fu540.h | 47 - > > > > 23 files changed, 370 insertions(+), 367 deletions(-) > > > > delete mode 100644 arch/riscv/cpu/generic/Kconfig > > > > delete mode 100644 arch/riscv/cpu/generic/Makefile > > > > delete mode 100644 arch/riscv/cpu/generic/cpu.c > > > > delete mode 100644 arch/riscv/cpu/generic/dram.c > > > > create mode 100644 arch/riscv/cpu/u54-mc/Kconfig > > > > create mode 100644 arch/riscv/cpu/u54-mc/Makefile > > > > create mode 100644 arch/riscv/cpu/u54-mc/cpu.c > > > > create mode 100644 arch/riscv/cpu/u54-mc/dram.c > > > > create mode 100644 arch/riscv/include/asm/arch-fu540-c000/clk.h > > > > delete mode 100644 arch/riscv/include/asm/arch-generic/clk.h > > > > delete mode 100644 board/sifive/fu540/Kconfig > > > > delete mode 100644 board/sifive/fu540/MAINTAINERS > > > > delete mode 100644 board/sifive/fu540/Makefile > > > > delete mode 100644 board/sifive/fu540/fu540.c > > > > create mode 100644 board/sifive/hifive_unleashed/Kconfig > > > > create mode 100644 board/sifive/hifive_unleashed/MAINTAINERS > > > > create mode 100644 board/sifive/hifive_unleashed/Makefile > > > > create mode 100644 board/sifive/hifive_unleashed/fu540.c > > > > create mode 100644 configs/hifive_unleashed_defconfig > > > > delete mode 100644 configs/sifive_fu540_defconfig > > > > create mode 100644 include/configs/hifive_unleashed.h > > > > delete mode 100644 include/configs/sifive-fu540.h > > > > > > > > > > I agree with Bin's concerns. > > > > > > Please don't rename generic CPU support under arch/riscv > > > > > > We should think long-term here. If every SOC vendor starts adding > > > their CPU support directory under arch/riscv then U-Boot RISC port > > > will be eventually difficult to manage and we will also have duplicate > > > code across various CPU support. > > > > > > IMHO, we should avoid adding new CPU support under arch/riscv > > > as much as possible. We can call weak functions from generic CPU > > > support and board support code can implement it. We should only > > > add new CPU support under arch/riscv whe
Re: [U-Boot] [PATCH] sifive: riscv: update Hifive Unleashed configuration infrastructure
Hello Anup, On Tue, Jul 30, 2019 at 9:12 AM Anup Patel wrote: > > On Mon, Jul 29, 2019 at 6:13 PM Sagar Shrikant Kadam > wrote: > > > > This patch aligns the current implementation of HiFive Unleashed > > board configuration framework with the one described in doc/README.kconfig. > > > > Signed-off-by: Sagar Shrikant Kadam > > --- > > arch/riscv/Kconfig | 6 +- > > arch/riscv/cpu/generic/Kconfig | 12 --- > > arch/riscv/cpu/generic/Makefile | 6 -- > > arch/riscv/cpu/generic/cpu.c | 35 --- > > arch/riscv/cpu/generic/dram.c| 37 --- > > arch/riscv/cpu/u54-mc/Kconfig| 12 +++ > > arch/riscv/cpu/u54-mc/Makefile | 6 ++ > > arch/riscv/cpu/u54-mc/cpu.c | 35 +++ > > arch/riscv/cpu/u54-mc/dram.c | 37 +++ > > arch/riscv/include/asm/arch-fu540-c000/clk.h | 14 +++ > > arch/riscv/include/asm/arch-generic/clk.h| 14 --- > > board/sifive/fu540/Kconfig | 49 -- > > board/sifive/fu540/MAINTAINERS | 9 -- > > board/sifive/fu540/Makefile | 5 - > > board/sifive/fu540/fu540.c | 139 > > --- > > board/sifive/hifive_unleashed/Kconfig| 52 ++ > > board/sifive/hifive_unleashed/MAINTAINERS| 9 ++ > > board/sifive/hifive_unleashed/Makefile | 5 + > > board/sifive/hifive_unleashed/fu540.c| 139 > > +++ > > configs/hifive_unleashed_defconfig | 11 +++ > > configs/sifive_fu540_defconfig | 11 --- > > include/configs/hifive_unleashed.h | 47 + > > include/configs/sifive-fu540.h | 47 - > > 23 files changed, 370 insertions(+), 367 deletions(-) > > delete mode 100644 arch/riscv/cpu/generic/Kconfig > > delete mode 100644 arch/riscv/cpu/generic/Makefile > > delete mode 100644 arch/riscv/cpu/generic/cpu.c > > delete mode 100644 arch/riscv/cpu/generic/dram.c > > create mode 100644 arch/riscv/cpu/u54-mc/Kconfig > > create mode 100644 arch/riscv/cpu/u54-mc/Makefile > > create mode 100644 arch/riscv/cpu/u54-mc/cpu.c > > create mode 100644 arch/riscv/cpu/u54-mc/dram.c > > create mode 100644 arch/riscv/include/asm/arch-fu540-c000/clk.h > > delete mode 100644 arch/riscv/include/asm/arch-generic/clk.h > > delete mode 100644 board/sifive/fu540/Kconfig > > delete mode 100644 board/sifive/fu540/MAINTAINERS > > delete mode 100644 board/sifive/fu540/Makefile > > delete mode 100644 board/sifive/fu540/fu540.c > > create mode 100644 board/sifive/hifive_unleashed/Kconfig > > create mode 100644 board/sifive/hifive_unleashed/MAINTAINERS > > create mode 100644 board/sifive/hifive_unleashed/Makefile > > create mode 100644 board/sifive/hifive_unleashed/fu540.c > > create mode 100644 configs/hifive_unleashed_defconfig > > delete mode 100644 configs/sifive_fu540_defconfig > > create mode 100644 include/configs/hifive_unleashed.h > > delete mode 100644 include/configs/sifive-fu540.h > > > > I agree with Bin's concerns. > > Please don't rename generic CPU support under arch/riscv > > We should think long-term here. If every SOC vendor starts adding > their CPU support directory under arch/riscv then U-Boot RISC port > will be eventually difficult to manage and we will also have duplicate > code across various CPU support. > > IMHO, we should avoid adding new CPU support under arch/riscv > as much as possible. We can call weak functions from generic CPU > support and board support code can implement it. We should only > add new CPU support under arch/riscv when we are not able to > re-use generic CPU support. > Yes, your points are valid. I am Ok with it. My intent here was that as the support for riscv in U-boot is in its early stages and doing it now would be better as minimum changes will be required and going ahead as other CPU vendors introduce their CPU under arch/riscv/ we could isolate a generic CPU code as it grows. > > Other board support renaming is fine but there is lot of documentation If board support renaming is fine. Shall I submit another patch excluding the CPU changes? Thanks & BR, Sagar Kadam > > > in U-Boot, OpenSBI and other places which needs to be also updated. > > Regards, > Anup ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] sifive: riscv: update Hifive Unleashed configuration infrastructure
Hello Bin, On Mon, Jul 29, 2019 at 7:15 PM Bin Meng wrote: > > Hi, > > On Mon, Jul 29, 2019 at 8:42 PM Sagar Shrikant Kadam > wrote: > > > > This patch aligns the current implementation of HiFive Unleashed > > board configuration framework with the one described in doc/README.kconfig. > > > > Can you please explain why these changes are needed? It looks that the > changes are only to rename the "generic" cpu name to "u54-mc", and > rename the board name "fu540" to "hifive_unleashed"? > This patch is intended to update the naming convention which U-boot mentions in doc/README.kconfig. As we know that FU540-C000 has a U54-MC CPU core, I thought of naming it as u54-mc and board name from fu540 to hifive_unleashed which is the actual case. > This breaks the QEMU virt boards. > Unfortunately yes. Hence I raised a request in the cover letter for suggestions accordingly. > > Signed-off-by: Sagar Shrikant Kadam > > --- > > arch/riscv/Kconfig | 6 +- > > arch/riscv/cpu/generic/Kconfig | 12 --- > > arch/riscv/cpu/generic/Makefile | 6 -- > > arch/riscv/cpu/generic/cpu.c | 35 --- > > arch/riscv/cpu/generic/dram.c| 37 --- > > arch/riscv/cpu/u54-mc/Kconfig| 12 +++ > > arch/riscv/cpu/u54-mc/Makefile | 6 ++ > > arch/riscv/cpu/u54-mc/cpu.c | 35 +++ > > arch/riscv/cpu/u54-mc/dram.c | 37 +++ > > arch/riscv/include/asm/arch-fu540-c000/clk.h | 14 +++ > > arch/riscv/include/asm/arch-generic/clk.h| 14 --- > > board/sifive/fu540/Kconfig | 49 -- > > board/sifive/fu540/MAINTAINERS | 9 -- > > board/sifive/fu540/Makefile | 5 - > > board/sifive/fu540/fu540.c | 139 > > --- > > board/sifive/hifive_unleashed/Kconfig| 52 ++ > > board/sifive/hifive_unleashed/MAINTAINERS| 9 ++ > > board/sifive/hifive_unleashed/Makefile | 5 + > > board/sifive/hifive_unleashed/fu540.c| 139 > > +++ > > configs/hifive_unleashed_defconfig | 11 +++ > > configs/sifive_fu540_defconfig | 11 --- > > include/configs/hifive_unleashed.h | 47 + > > include/configs/sifive-fu540.h | 47 - > > 23 files changed, 370 insertions(+), 367 deletions(-) > > delete mode 100644 arch/riscv/cpu/generic/Kconfig > > delete mode 100644 arch/riscv/cpu/generic/Makefile > > delete mode 100644 arch/riscv/cpu/generic/cpu.c > > delete mode 100644 arch/riscv/cpu/generic/dram.c > > It looks that you did not use "git mv" command. > I do remember using "git mv" here. Probably adding '-M' (detect renames) switch to git format-patch would have helped to include the renamed files instead of delete and create information. Next time I will ensure to include it. Thanks for pointing this. BR, Sagar Kadam > > create mode 100644 arch/riscv/cpu/u54-mc/Kconfig > > create mode 100644 arch/riscv/cpu/u54-mc/Makefile > > create mode 100644 arch/riscv/cpu/u54-mc/cpu.c > > create mode 100644 arch/riscv/cpu/u54-mc/dram.c > > create mode 100644 arch/riscv/include/asm/arch-fu540-c000/clk.h > > delete mode 100644 arch/riscv/include/asm/arch-generic/clk.h > > delete mode 100644 board/sifive/fu540/Kconfig > > delete mode 100644 board/sifive/fu540/MAINTAINERS > > delete mode 100644 board/sifive/fu540/Makefile > > delete mode 100644 board/sifive/fu540/fu540.c > > create mode 100644 board/sifive/hifive_unleashed/Kconfig > > create mode 100644 board/sifive/hifive_unleashed/MAINTAINERS > > create mode 100644 board/sifive/hifive_unleashed/Makefile > > create mode 100644 board/sifive/hifive_unleashed/fu540.c > > create mode 100644 configs/hifive_unleashed_defconfig > > delete mode 100644 configs/sifive_fu540_defconfig > > create mode 100644 include/configs/hifive_unleashed.h > > delete mode 100644 include/configs/sifive-fu540.h > > > > Regards, > Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] riscv : serial: use rx watermark to indicate rx data is present
Hi Rick,
On Fri, Jul 26, 2019 at 12:32 PM Rick Chen wrote:
>
> Hi Sagar
>
> > From: Sagar Kadam [mailto:sagar.ka...@sifive.com]
> > Sent: Friday, July 19, 2019 7:37 PM
> > To: Rick Jian-Zhi Chen(陳建志)
> > Subject: Re: [U-Boot] [PATCH] riscv : serial: use rx watermark to indicate
> > rx data is present
> >
> > Hello Rick,
> >
> > I missed to CC you while submitting the patch[1] Can you please provide
> > your view's on the patch.
>
> Sorry for the late response.
> I am OK with your patch.
> I will pull it into riscv tree ASAP :)
>
> B.R
> Rick
>
Thanks for acknowledgement :)
Regards,
Sagar
> >
> > [1] https://patchwork.ozlabs.org/patch/1129736/
> >
> >
> > Thanks & Regards,
> > Sagar Kadam
> >
> > > Thank you for the review and testing the changes.
> >
> > On Fri, Jul 19, 2019 at 5:04 PM Sagar Kadam wrote:
> > >
> > > Hello Rick,
> > >
> > Sorry accidently pressed the send button after this :)
> >
> > > On Mon, Jul 15, 2019 at 5:52 PM Sagar Kadam
> > > wrote:
> > > >
> > > > Hi Padmarao,
> > > >
> > > > On Mon, Jul 15, 2019 at 5:31 PM Padmarao Begari
> > > > wrote:
> > > > >
> > > > > Reviewed-by: Padmarao Begari
> > > > > Tested-by: Padmarao Begari
> > > > >
> > > >
> > > >
> > > > > Regards
> > > > > Padmarao
> > > > >
> > > >
> > > > BR,
> > > > Sagar Kadam
> > > > > On Tue, Jul 9, 2019 at 5:56 PM Sagar Shrikant Kadam
> > > > > wrote:
> > > > >>
> > > > >> In y-modem transfer mode, tstc/getc fail to check if there is any
> > > > >> data available / received in RX FIFO, and so y-modem transfer
> > > > >> never succeeds. Using receive watermark bit within ip register
> > > > >> fixes the issue.
> > > > >>
> > > > >> This patch is based on commit c7392b7bc4e1 ("Use the RX watermark
> > > > >> interrupt pending bit for TSTC") available at[1]
> > > > >>
> > > > >> [1] https://github.com/sifive/HiFive_U-Boot/tree/regression
> > > > >>
> > > > >> Signed-off-by: Sagar Shrikant Kadam
> > > > >> ---
> > > > >>
> > > > >> drivers/serial/serial_sifive.c | 23 +++
> > > > >> 1 file changed, 7 insertions(+), 16 deletions(-)
> > > > >>
> > > > >> diff --git a/drivers/serial/serial_sifive.c
> > > > >> b/drivers/serial/serial_sifive.c index fdfef69..c142ccd 100644
> > > > >> --- a/drivers/serial/serial_sifive.c
> > > > >> +++ b/drivers/serial/serial_sifive.c
> > > > >> @@ -22,6 +22,9 @@ DECLARE_GLOBAL_DATA_PTR;
> > > > >> #define UART_TXCTRL_TXEN 0x1
> > > > >> #define UART_RXCTRL_RXEN 0x1
> > > > >>
> > > > >> +/* IP register */
> > > > >> +#define UART_IP_RXWM0x2
> > > > >> +
> > > > >> struct uart_sifive {
> > > > >> u32 txfifo;
> > > > >> u32 rxfifo;
> > > > >> @@ -34,7 +37,6 @@ struct uart_sifive {
> > > > >>
> > > > >> struct sifive_uart_platdata {
> > > > >> unsigned long clock;
> > > > >> - int saved_input_char;
> > > > >> struct uart_sifive *regs; };
> > > > >>
> > > > >> @@ -94,7 +96,7 @@ static int _sifive_serial_getc(struct uart_sifive
> > > > >> *regs)
> > > > >> return -EAGAIN;
> > > > >> ch &= UART_RXFIFO_DATA;
> > > > >>
> > > > >> - return (!ch) ? -EAGAIN : ch;
> > > > >> + return ch;
> > > > >> }
> > > > >>
> > > > >> static int sifive_serial_setbrg(struct udevice *dev, int
> > > > >> baudrate) @@ -133,7 +135,6 @@ static int sifive_serial_probe(struct
> > > > >> udevice *dev)
> > > > >> if (gd->flags & GD_FLG_RELOC)
> > > > >> return 0;
> > > > >>
> > > > >> - platdata->sav
Re: [U-Boot] [PATCH v6 0/4] SiFive SPI MMC Support
Hi, On Wed, Jul 17, 2019 at 9:54 AM Anup Patel wrote: > > This patchset adds: > 1. SiFive SPI driver > 2. New MMC SPI driver based on DM_MMC and DM_SPI > 3. Enables SiFive SPI driver and MMC SPI driver for SiFive Unleashed board > > With this patch series, we can now load files from SD card on SiFive > Unleashed board. Many thanks to Bhargav for porting SiFive SPI driver > and updating MMC SPI driver for us. > > These patches can be also found in riscv_unleashed_mmc_spi_v6 branch of: > https//github.com/avpatel/u-boot.git > > Changes since v5: > - Added sifive_spi_cs_info() callback with sanity check on valid chip-select > > Changes since v4: > - Renamed kconfig option from SIFIVE_SPI to SPI_SIFIVE for consistency > - Added dummy claim_bus() and release_bus() callbacks > > Changes since v3: > - Removed PATCH2, PATCH3, and PATCH4 because these are already merged > - Added separate patch to use SPI_XFER_xyz flags in MMC_SPI driver > - Use readl/writel directly instead of sifive_spi_read/sifi_spi_write > - Use SPI_XFER_xyz flags to enable/disable chipselect > - Remove unused callback sifive_spi_cs_info() > > Changes since v2: > - Minor fixes in PATCH1 which adds SiFive SPI driver > - Removed CONFIG_MMC_SPI_xyz from scripts/config_whitelist.txt > - Removed cmd/mmc_spi and all its refrences as separate patch > - Removed DM_SPI and DM_MMC from SiFive FU540 Kconfig > > Changes since v1: > - Make response matching part belongs to mmc_spi_sendcmd() > - Match response to zero for SEND_STATUS (CMD13) > - Add separate patch for updating SiFive FU540 Documentation > > Anup Patel (2): > mmc: mmc_spi: Use SPI_XFER_BEGIN and SPI_XFER_END flags > doc: sifive-fu540: Update README for SiFive SPI and MMC SPI drivers > > Bhargav Shah (2): > spi: Add SiFive SPI driver > riscv: sifive: fu540: Enable SiFive SPI and MMC SPI drivers > > board/sifive/fu540/Kconfig | 6 + > doc/README.sifive-fu540| 4 +- > drivers/mmc/mmc_spi.c | 4 +- > drivers/spi/Kconfig| 8 + > drivers/spi/Makefile | 1 + > drivers/spi/spi-sifive.c | 370 +++++ > 6 files changed, 389 insertions(+), 4 deletions(-) > create mode 100644 drivers/spi/spi-sifive.c > The series looks good. Tested-by: Sagar Kadam > -- > 2.17.1 > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] riscv : serial: use rx watermark to indicate rx data is present
Hi Padmarao,
On Mon, Jul 15, 2019 at 5:31 PM Padmarao Begari wrote:
>
> Reviewed-by: Padmarao Begari
> Tested-by: Padmarao Begari
>
Thank you for the review and testing the changes.
> Regards
> Padmarao
>
BR,
Sagar Kadam
> On Tue, Jul 9, 2019 at 5:56 PM Sagar Shrikant Kadam
> wrote:
>>
>> In y-modem transfer mode, tstc/getc fail to check if there is any
>> data available / received in RX FIFO, and so y-modem transfer never
>> succeeds. Using receive watermark bit within ip register fixes the
>> issue.
>>
>> This patch is based on commit c7392b7bc4e1 ("Use the RX watermark
>> interrupt pending bit for TSTC") available at[1]
>>
>> [1] https://github.com/sifive/HiFive_U-Boot/tree/regression
>>
>> Signed-off-by: Sagar Shrikant Kadam
>> ---
>>
>> drivers/serial/serial_sifive.c | 23 +++
>> 1 file changed, 7 insertions(+), 16 deletions(-)
>>
>> diff --git a/drivers/serial/serial_sifive.c b/drivers/serial/serial_sifive.c
>> index fdfef69..c142ccd 100644
>> --- a/drivers/serial/serial_sifive.c
>> +++ b/drivers/serial/serial_sifive.c
>> @@ -22,6 +22,9 @@ DECLARE_GLOBAL_DATA_PTR;
>> #define UART_TXCTRL_TXEN 0x1
>> #define UART_RXCTRL_RXEN 0x1
>>
>> +/* IP register */
>> +#define UART_IP_RXWM0x2
>> +
>> struct uart_sifive {
>> u32 txfifo;
>> u32 rxfifo;
>> @@ -34,7 +37,6 @@ struct uart_sifive {
>>
>> struct sifive_uart_platdata {
>> unsigned long clock;
>> - int saved_input_char;
>> struct uart_sifive *regs;
>> };
>>
>> @@ -94,7 +96,7 @@ static int _sifive_serial_getc(struct uart_sifive *regs)
>> return -EAGAIN;
>> ch &= UART_RXFIFO_DATA;
>>
>> - return (!ch) ? -EAGAIN : ch;
>> + return ch;
>> }
>>
>> static int sifive_serial_setbrg(struct udevice *dev, int baudrate)
>> @@ -133,7 +135,6 @@ static int sifive_serial_probe(struct udevice *dev)
>> if (gd->flags & GD_FLG_RELOC)
>> return 0;
>>
>> - platdata->saved_input_char = 0;
>> _sifive_serial_init(platdata->regs);
>>
>> return 0;
>> @@ -145,12 +146,6 @@ static int sifive_serial_getc(struct udevice *dev)
>> struct sifive_uart_platdata *platdata = dev_get_platdata(dev);
>> struct uart_sifive *regs = platdata->regs;
>>
>> - if (platdata->saved_input_char > 0) {
>> - c = platdata->saved_input_char;
>> - platdata->saved_input_char = 0;
>> - return c;
>> - }
>> -
>> while ((c = _sifive_serial_getc(regs)) == -EAGAIN) ;
>>
>> return c;
>> @@ -171,14 +166,10 @@ static int sifive_serial_pending(struct udevice *dev,
>> bool input)
>> struct sifive_uart_platdata *platdata = dev_get_platdata(dev);
>> struct uart_sifive *regs = platdata->regs;
>>
>> - if (input) {
>> - if (platdata->saved_input_char > 0)
>> - return 1;
>> - platdata->saved_input_char = _sifive_serial_getc(regs);
>> - return (platdata->saved_input_char > 0) ? 1 : 0;
>> - } else {
>> + if (input)
>> + return (readl(>ip) & UART_IP_RXWM);
>> + else
>> return !!(readl(>txfifo) & UART_TXFIFO_FULL);
>> - }
>> }
>>
>> static int sifive_serial_ofdata_to_platdata(struct udevice *dev)
>> --
>> 2.7.4
>>
>> ___
>> U-Boot mailing list
>> U-Boot@lists.denx.de
>> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] riscv : serial: use rx watermark to indicate rx data is present
Hi Anup,
On Wed, Jul 10, 2019 at 10:03 AM Anup Patel wrote:
>
> On Tue, Jul 9, 2019 at 5:55 PM Sagar Shrikant Kadam
> wrote:
> >
> > In y-modem transfer mode, tstc/getc fail to check if there is any
> > data available / received in RX FIFO, and so y-modem transfer never
> > succeeds. Using receive watermark bit within ip register fixes the
> > issue.
> >
> > This patch is based on commit c7392b7bc4e1 ("Use the RX watermark
> > interrupt pending bit for TSTC") available at[1]
> >
> > [1] https://github.com/sifive/HiFive_U-Boot/tree/regression
> >
> > Signed-off-by: Sagar Shrikant Kadam
> > ---
> >
> > drivers/serial/serial_sifive.c | 23 +++
> > 1 file changed, 7 insertions(+), 16 deletions(-)
> >
> > diff --git a/drivers/serial/serial_sifive.c b/drivers/serial/serial_sifive.c
> > index fdfef69..c142ccd 100644
> > --- a/drivers/serial/serial_sifive.c
> > +++ b/drivers/serial/serial_sifive.c
> > @@ -22,6 +22,9 @@ DECLARE_GLOBAL_DATA_PTR;
> > #define UART_TXCTRL_TXEN 0x1
> > #define UART_RXCTRL_RXEN 0x1
> >
> > +/* IP register */
> > +#define UART_IP_RXWM0x2
> > +
> > struct uart_sifive {
> > u32 txfifo;
> > u32 rxfifo;
> > @@ -34,7 +37,6 @@ struct uart_sifive {
> >
> > struct sifive_uart_platdata {
> > unsigned long clock;
> > - int saved_input_char;
> > struct uart_sifive *regs;
> > };
> >
> > @@ -94,7 +96,7 @@ static int _sifive_serial_getc(struct uart_sifive *regs)
> > return -EAGAIN;
> > ch &= UART_RXFIFO_DATA;
> >
> > - return (!ch) ? -EAGAIN : ch;
> > + return ch;
> > }
> >
> > static int sifive_serial_setbrg(struct udevice *dev, int baudrate)
> > @@ -133,7 +135,6 @@ static int sifive_serial_probe(struct udevice *dev)
> > if (gd->flags & GD_FLG_RELOC)
> > return 0;
> >
> > - platdata->saved_input_char = 0;
> > _sifive_serial_init(platdata->regs);
> >
> > return 0;
> > @@ -145,12 +146,6 @@ static int sifive_serial_getc(struct udevice *dev)
> > struct sifive_uart_platdata *platdata = dev_get_platdata(dev);
> > struct uart_sifive *regs = platdata->regs;
> >
> > - if (platdata->saved_input_char > 0) {
> > - c = platdata->saved_input_char;
> > - platdata->saved_input_char = 0;
> > - return c;
> > - }
> > -
> > while ((c = _sifive_serial_getc(regs)) == -EAGAIN) ;
> >
> > return c;
> > @@ -171,14 +166,10 @@ static int sifive_serial_pending(struct udevice *dev,
> > bool input)
> > struct sifive_uart_platdata *platdata = dev_get_platdata(dev);
> > struct uart_sifive *regs = platdata->regs;
> >
> > - if (input) {
> > - if (platdata->saved_input_char > 0)
> > - return 1;
> > - platdata->saved_input_char = _sifive_serial_getc(regs);
> > - return (platdata->saved_input_char > 0) ? 1 : 0;
> > - } else {
> > + if (input)
> > + return (readl(>ip) & UART_IP_RXWM);
> > + else
> > return !!(readl(>txfifo) & UART_TXFIFO_FULL);
> > - }
> > }
> >
> > static int sifive_serial_ofdata_to_platdata(struct udevice *dev)
> > --
> > 2.7.4
> >
>
> Looks good to me.
>
> Reviewed-by: Anup Patel
> Tested-by: Anup Patel
>
Thank you for testing it.
> Regards,
> Anup
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
