Linux-RISC-V Archive on lore.kernel.org
 help / color / Atom feed
* 5.2-rc1 boot on Unleashed
@ 2019-05-20 23:31 Atish Patra
  2019-05-21  9:40 ` Andreas Schwab
                   ` (3 more replies)
  0 siblings, 4 replies; 42+ messages in thread
From: Atish Patra @ 2019-05-20 23:31 UTC (permalink / raw)
  To: paul.walmsley, Palmer Dabbelt, Björn Töpel; +Cc: linux-riscv

Hi,

5.2-rc1 still requires some out-of-tree driver patches.

Here is my tree (successfully tested on Unleashed.)
https://github.com/atishp04/linux/tree/5.2-rc1_unleashed

Issues:

1. Thanks to Paul, uart & clock drivers are merged. However,
	a. upstream clock drivers require DT changes
	b. Those DT changes are still being reviewed.
	c. FSBL need to be rebuild & updated for these DT changes.

That's why I am still using the old out-of-tree clock drivers for now.

@Paul, @Palmer: Can SiFive share the updated FSBL binary so that 
everybody can use the upstream clock drivers without having to rebuild 
FSBL by hand?


2. We still need the following networking hack. I had to rebase the 
patch on top of 5.2-rc1.
-----------------------------------------------------------------
commit 1cae94e4f38f (HEAD -> 5.2-rc1_unleashed, atishp04/5.2-rc1_unleashed)
Author: Atish Patra <atish.patra@wdc.com>
Date:   Fri Sep 7 10:22:27 2018 -0700

     RISC-V: Networking fix Hack

     It looks like that kernel driver now supports reseting the
     signal one additional time. As it had been  already reset
     twice in FSBL, PHY gets into incorrect state causing below error.

     ----------------------------------------------------------------------
     macb 10090000.ethernet (unnamed net_device) (uninitialized): Could 
not attach to PHY
     macb: probe of 10090000.ethernet failed with error -110
     ----------------------------------------------------------------------

     This patch is just a temporary fix until we have a fix a FSBL.
     It is just a **HACK** and **NOT TO BE MERGED** into mainline.

     Signed-off-by: Atish Patra <atish.patra@wdc.com>

diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
index bd04fe762056..4b99b226c885 100644
--- a/drivers/net/phy/mdio_bus.c
+++ b/drivers/net/phy/mdio_bus.c
@@ -94,9 +94,6 @@ int mdiobus_register_device(struct mdio_device *mdiodev)
                 err = mdiobus_register_reset(mdiodev);
                 if (err)
                         return err;
-
-               /* Assert the reset signal */
-               mdio_device_reset(mdiodev, 1);
         }

         mdiodev->bus->mdio_map[mdiodev->addr] = mdiodev;
-----------------------------------------------------------------

Can somebody please look into this so that we can avoid this ugly hack ?

-- 
Regards,
Atish

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: 5.2-rc1 boot on Unleashed
  2019-05-20 23:31 5.2-rc1 boot on Unleashed Atish Patra
@ 2019-05-21  9:40 ` Andreas Schwab
  2019-05-21 18:14   ` Atish Patra
  2019-05-21 17:47 ` Kevin Hilman
                   ` (2 subsequent siblings)
  3 siblings, 1 reply; 42+ messages in thread
From: Andreas Schwab @ 2019-05-21  9:40 UTC (permalink / raw)
  To: Atish Patra
  Cc: Björn Töpel, linux-riscv, Palmer Dabbelt, paul.walmsley

On Mai 20 2019, Atish Patra <atish.patra@wdc.com> wrote:

> 1. Thanks to Paul, uart & clock drivers are merged. However,
> 	a. upstream clock drivers require DT changes

How does it look like?

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: 5.2-rc1 boot on Unleashed
  2019-05-20 23:31 5.2-rc1 boot on Unleashed Atish Patra
  2019-05-21  9:40 ` Andreas Schwab
@ 2019-05-21 17:47 ` Kevin Hilman
  2019-05-21 18:18   ` Atish Patra
  2019-05-22  4:42 ` Sagar Kadam
  2019-05-22 16:42 ` Paul Walmsley
  3 siblings, 1 reply; 42+ messages in thread
From: Kevin Hilman @ 2019-05-21 17:47 UTC (permalink / raw)
  To: Atish Patra, paul.walmsley, Palmer Dabbelt, Björn Töpel
  Cc: linux-riscv

Atish Patra <atish.patra@wdc.com> writes:

> Hi,
>
> 5.2-rc1 still requires some out-of-tree driver patches.
>
> Here is my tree (successfully tested on Unleashed.)
> https://github.com/atishp04/linux/tree/5.2-rc1_unleashed
>
> Issues:
>
> 1. Thanks to Paul, uart & clock drivers are merged. However,
> 	a. upstream clock drivers require DT changes
> 	b. Those DT changes are still being reviewed.
> 	c. FSBL need to be rebuild & updated for these DT changes.

I would also add that due to DT changes required:

  d. Does not work with upstream u-boot

which is a blocker for fully-automated testing in kernelCI (unless
someone wants to work on the kernelCI support for BBL+FSBL. ;)

Kevin

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: 5.2-rc1 boot on Unleashed
  2019-05-21  9:40 ` Andreas Schwab
@ 2019-05-21 18:14   ` Atish Patra
  2019-05-22  7:31     ` Andreas Schwab
                       ` (2 more replies)
  0 siblings, 3 replies; 42+ messages in thread
From: Atish Patra @ 2019-05-21 18:14 UTC (permalink / raw)
  To: Andreas Schwab
  Cc: Björn Töpel, linux-riscv, Palmer Dabbelt, paul.walmsley

On 5/21/19 2:40 AM, Andreas Schwab wrote:
> On Mai 20 2019, Atish Patra <atish.patra@wdc.com> wrote:
> 
>> 1. Thanks to Paul, uart & clock drivers are merged. However,
>> 	a. upstream clock drivers require DT changes
> 
> How does it look like?
> 
> Andreas.
> 


Here is prci dt entry in Paul's patch series.

		prci: clock-controller at 10000000 {
			compatible = "sifive,fu540-c000-prci";
			reg = <0x0 0x10000000 0x0 0x1000>;
			clocks = <&hfclk>, <&rtcclk>;
			#clock-cells = <1>;
		};


while current DT from FSBL
(https://github.com/sifive/freedom-u540-c000-bootloader/blob/master/fsbl/ux00_fsbl.dts)

prci: prci at 10000000 {
			compatible = "sifive,aloeprci0", "sifive,ux00prci0";
			reg = <0x0 0x10000000 0x0 0x1000>;
			reg-names = "control";
			clocks = <&refclk>;
			#clock-cells = <1>;
		};

The details of error can be found here
http://lists.infradead.org/pipermail/linux-riscv/2019-April/004259.html

-- 
Regards,
Atish

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: 5.2-rc1 boot on Unleashed
  2019-05-21 17:47 ` Kevin Hilman
@ 2019-05-21 18:18   ` Atish Patra
  2019-05-23  9:42     ` Andreas Schwab
  0 siblings, 1 reply; 42+ messages in thread
From: Atish Patra @ 2019-05-21 18:18 UTC (permalink / raw)
  To: Kevin Hilman, paul.walmsley, Palmer Dabbelt, Björn Töpel
  Cc: linux-riscv

On 5/21/19 10:48 AM, Kevin Hilman wrote:
> Atish Patra <atish.patra@wdc.com> writes:
> 
>> Hi,
>>
>> 5.2-rc1 still requires some out-of-tree driver patches.
>>
>> Here is my tree (successfully tested on Unleashed.)
>> https://github.com/atishp04/linux/tree/5.2-rc1_unleashed
>>
>> Issues:
>>
>> 1. Thanks to Paul, uart & clock drivers are merged. However,
>> 	a. upstream clock drivers require DT changes
>> 	b. Those DT changes are still being reviewed.
>> 	c. FSBL need to be rebuild & updated for these DT changes.
> 
> I would also add that due to DT changes required:
> 
>    d. Does not work with upstream u-boot
> 

Yeah. I guess PRCI clock DT changes may not be backward compatible with 
U-Boot PRCI driver. Apart from FSBL update, we also need to patch U-Boot 
PRCI clock driver now.

> which is a blocker for fully-automated testing in kernelCI (unless
> someone wants to work on the kernelCI support for BBL+FSBL. ;)
> 
> Kevin
> 


-- 
Regards,
Atish

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: 5.2-rc1 boot on Unleashed
  2019-05-20 23:31 5.2-rc1 boot on Unleashed Atish Patra
  2019-05-21  9:40 ` Andreas Schwab
  2019-05-21 17:47 ` Kevin Hilman
@ 2019-05-22  4:42 ` Sagar Kadam
  2019-05-22  9:51   ` Atish Patra
  2019-05-22 16:42 ` Paul Walmsley
  3 siblings, 1 reply; 42+ messages in thread
From: Sagar Kadam @ 2019-05-22  4:42 UTC (permalink / raw)
  To: Atish Patra
  Cc: Björn Töpel, linux-riscv, Palmer Dabbelt, paul.walmsley

Hi Atish,


On Tue, May 21, 2019 at 5:03 AM Atish Patra <atish.patra@wdc.com> wrote:
>
> Hi,
>
> 5.2-rc1 still requires some out-of-tree driver patches.
>
> Here is my tree (successfully tested on Unleashed.)
> https://github.com/atishp04/linux/tree/5.2-rc1_unleashed
>
> Issues:
>
> 1. Thanks to Paul, uart & clock drivers are merged. However,
>         a. upstream clock drivers require DT changes
>         b. Those DT changes are still being reviewed.
>         c. FSBL need to be rebuild & updated for these DT changes.
>
> That's why I am still using the old out-of-tree clock drivers for now.
>
> @Paul, @Palmer: Can SiFive share the updated FSBL binary so that
> everybody can use the upstream clock drivers without having to rebuild
> FSBL by hand?
>
>
> 2. We still need the following networking hack. I had to rebase the
> patch on top of 5.2-rc1.
> -----------------------------------------------------------------
> commit 1cae94e4f38f (HEAD -> 5.2-rc1_unleashed, atishp04/5.2-rc1_unleashed)
> Author: Atish Patra <atish.patra@wdc.com>
> Date:   Fri Sep 7 10:22:27 2018 -0700
>
>      RISC-V: Networking fix Hack
>
>      It looks like that kernel driver now supports reseting the
>      signal one additional time. As it had been  already reset
>      twice in FSBL, PHY gets into incorrect state causing below error.
>
>      ----------------------------------------------------------------------
>      macb 10090000.ethernet (unnamed net_device) (uninitialized): Could
> not attach to PHY
>      macb: probe of 10090000.ethernet failed with error -110
>      ----------------------------------------------------------------------
>
>      This patch is just a temporary fix until we have a fix a FSBL.
>      It is just a **HACK** and **NOT TO BE MERGED** into mainline.
>
>      Signed-off-by: Atish Patra <atish.patra@wdc.com>
>
> diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
> index bd04fe762056..4b99b226c885 100644
> --- a/drivers/net/phy/mdio_bus.c
> +++ b/drivers/net/phy/mdio_bus.c
> @@ -94,9 +94,6 @@ int mdiobus_register_device(struct mdio_device *mdiodev)
>                  err = mdiobus_register_reset(mdiodev);
>                  if (err)
>                          return err;
> -
> -               /* Assert the reset signal */
> -               mdio_device_reset(mdiodev, 1);
>          }
>
>          mdiodev->bus->mdio_map[mdiodev->addr] = mdiodev;
> -----------------------------------------------------------------
>
> Can somebody please look into this so that we can avoid this ugly hack ?
>
Yes, I will look into this and submit a patch for the same.

Thanks & BR,
Sagar Kadam

> --
> Regards,
> Atish
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: 5.2-rc1 boot on Unleashed
  2019-05-21 18:14   ` Atish Patra
@ 2019-05-22  7:31     ` Andreas Schwab
  2019-05-22  8:40     ` Andreas Schwab
  2019-05-22  9:58     ` Andreas Schwab
  2 siblings, 0 replies; 42+ messages in thread
From: Andreas Schwab @ 2019-05-22  7:31 UTC (permalink / raw)
  To: Atish Patra
  Cc: Björn Töpel, linux-riscv, Palmer Dabbelt, paul.walmsley

On Mai 21 2019, Atish Patra <atish.patra@wdc.com> wrote:

> On 5/21/19 2:40 AM, Andreas Schwab wrote:
>> On Mai 20 2019, Atish Patra <atish.patra@wdc.com> wrote:
>>
>>> 1. Thanks to Paul, uart & clock drivers are merged. However,
>>> 	a. upstream clock drivers require DT changes
>>
>> How does it look like?
>>
>> Andreas.
>>
>
>
> Here is prci dt entry in Paul's patch series.
>
> 		prci: clock-controller at 10000000 {
> 			compatible = "sifive,fu540-c000-prci";
> 			reg = <0x0 0x10000000 0x0 0x1000>;
> 			clocks = <&hfclk>, <&rtcclk>;
> 			#clock-cells = <1>;
> 		};

But how about the clocks?

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: 5.2-rc1 boot on Unleashed
  2019-05-21 18:14   ` Atish Patra
  2019-05-22  7:31     ` Andreas Schwab
@ 2019-05-22  8:40     ` Andreas Schwab
  2019-05-22  9:58     ` Andreas Schwab
  2 siblings, 0 replies; 42+ messages in thread
From: Andreas Schwab @ 2019-05-22  8:40 UTC (permalink / raw)
  To: Atish Patra
  Cc: Björn Töpel, linux-riscv, Palmer Dabbelt, paul.walmsley

On Mai 21 2019, Atish Patra <atish.patra@wdc.com> wrote:

> 		prci: clock-controller at 10000000 {
> 			compatible = "sifive,fu540-c000-prci";

U-boot is looking for sifive,fu540-c000-prci0.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: 5.2-rc1 boot on Unleashed
  2019-05-22  4:42 ` Sagar Kadam
@ 2019-05-22  9:51   ` Atish Patra
  0 siblings, 0 replies; 42+ messages in thread
From: Atish Patra @ 2019-05-22  9:51 UTC (permalink / raw)
  To: Sagar Kadam
  Cc: Björn Töpel, linux-riscv, Palmer Dabbelt, paul.walmsley

On 5/21/19 9:42 PM, Sagar Kadam wrote:
> Hi Atish,
> 
> 
> On Tue, May 21, 2019 at 5:03 AM Atish Patra <atish.patra@wdc.com> wrote:
>>
>> Hi,
>>
>> 5.2-rc1 still requires some out-of-tree driver patches.
>>
>> Here is my tree (successfully tested on Unleashed.)
>> https://github.com/atishp04/linux/tree/5.2-rc1_unleashed
>>
>> Issues:
>>
>> 1. Thanks to Paul, uart & clock drivers are merged. However,
>>          a. upstream clock drivers require DT changes
>>          b. Those DT changes are still being reviewed.
>>          c. FSBL need to be rebuild & updated for these DT changes.
>>
>> That's why I am still using the old out-of-tree clock drivers for now.
>>
>> @Paul, @Palmer: Can SiFive share the updated FSBL binary so that
>> everybody can use the upstream clock drivers without having to rebuild
>> FSBL by hand?
>>
>>
>> 2. We still need the following networking hack. I had to rebase the
>> patch on top of 5.2-rc1.
>> -----------------------------------------------------------------
>> commit 1cae94e4f38f (HEAD -> 5.2-rc1_unleashed, atishp04/5.2-rc1_unleashed)
>> Author: Atish Patra <atish.patra@wdc.com>
>> Date:   Fri Sep 7 10:22:27 2018 -0700
>>
>>       RISC-V: Networking fix Hack
>>
>>       It looks like that kernel driver now supports reseting the
>>       signal one additional time. As it had been  already reset
>>       twice in FSBL, PHY gets into incorrect state causing below error.
>>
>>       ----------------------------------------------------------------------
>>       macb 10090000.ethernet (unnamed net_device) (uninitialized): Could
>> not attach to PHY
>>       macb: probe of 10090000.ethernet failed with error -110
>>       ----------------------------------------------------------------------
>>
>>       This patch is just a temporary fix until we have a fix a FSBL.
>>       It is just a **HACK** and **NOT TO BE MERGED** into mainline.
>>
>>       Signed-off-by: Atish Patra <atish.patra@wdc.com>
>>
>> diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
>> index bd04fe762056..4b99b226c885 100644
>> --- a/drivers/net/phy/mdio_bus.c
>> +++ b/drivers/net/phy/mdio_bus.c
>> @@ -94,9 +94,6 @@ int mdiobus_register_device(struct mdio_device *mdiodev)
>>                   err = mdiobus_register_reset(mdiodev);
>>                   if (err)
>>                           return err;
>> -
>> -               /* Assert the reset signal */
>> -               mdio_device_reset(mdiodev, 1);
>>           }
>>
>>           mdiodev->bus->mdio_map[mdiodev->addr] = mdiodev;
>> -----------------------------------------------------------------
>>
>> Can somebody please look into this so that we can avoid this ugly hack ?
>>
> Yes, I will look into this and submit a patch for the same.
> 

Thanks. Are you or anybody else form SiFive looking to upstream the GPIO 
driver?

I think that's the only driver remaining.

> Thanks & BR,
> Sagar Kadam
> 
>> --
>> Regards,
>> Atish
>>
>> _______________________________________________
>> linux-riscv mailing list
>> linux-riscv@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-riscv
> 


-- 
Regards,
Atish

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: 5.2-rc1 boot on Unleashed
  2019-05-21 18:14   ` Atish Patra
  2019-05-22  7:31     ` Andreas Schwab
  2019-05-22  8:40     ` Andreas Schwab
@ 2019-05-22  9:58     ` Andreas Schwab
  2019-05-22 21:13       ` Paul Walmsley
  2 siblings, 1 reply; 42+ messages in thread
From: Andreas Schwab @ 2019-05-22  9:58 UTC (permalink / raw)
  To: Atish Patra
  Cc: Björn Töpel, linux-riscv, Palmer Dabbelt, paul.walmsley

What does that mean?

[    9.538450] of_fixed_factor_clk: probe of soc:tlclk failed with error -17

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: 5.2-rc1 boot on Unleashed
  2019-05-20 23:31 5.2-rc1 boot on Unleashed Atish Patra
                   ` (2 preceding siblings ...)
  2019-05-22  4:42 ` Sagar Kadam
@ 2019-05-22 16:42 ` Paul Walmsley
  2019-05-22 17:38   ` Atish Patra
  3 siblings, 1 reply; 42+ messages in thread
From: Paul Walmsley @ 2019-05-22 16:42 UTC (permalink / raw)
  To: Atish Patra; +Cc: Björn Töpel, linux-riscv, Palmer Dabbelt

On Mon, 20 May 2019, Atish Patra wrote:

> @Paul, @Palmer: Can SiFive share the updated FSBL binary so that everybody can
> use the upstream clock drivers without having to rebuild FSBL by hand?

Am checking on this now and hope to have some conclusion on it this week.


- Paul

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: 5.2-rc1 boot on Unleashed
  2019-05-22 16:42 ` Paul Walmsley
@ 2019-05-22 17:38   ` Atish Patra
  2019-05-22 20:43     ` Paul Walmsley
  0 siblings, 1 reply; 42+ messages in thread
From: Atish Patra @ 2019-05-22 17:38 UTC (permalink / raw)
  To: Paul Walmsley; +Cc: Björn Töpel, linux-riscv, Palmer Dabbelt

On 5/22/19 9:42 AM, Paul Walmsley wrote:
> Am checking on this now and hope to have some conclusion on it this week.

Thanks. Any chance you can take a look at the U-Boot clock driver to 
patch it as per the DT changes ?

-- 
Regards,
Atish

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: 5.2-rc1 boot on Unleashed
  2019-05-22 17:38   ` Atish Patra
@ 2019-05-22 20:43     ` Paul Walmsley
  2019-05-22 22:14       ` Troy Benjegerdes
  2019-05-24  0:23       ` Troy Benjegerdes
  0 siblings, 2 replies; 42+ messages in thread
From: Paul Walmsley @ 2019-05-22 20:43 UTC (permalink / raw)
  To: Atish Patra
  Cc: troy.benjegerdes, Björn Töpel, linux-riscv,
	Palmer Dabbelt, anup.patel

+ Anup, Troy

On Wed, 22 May 2019, Atish Patra wrote:

> On 5/22/19 9:42 AM, Paul Walmsley wrote:
> > Am checking on this now and hope to have some conclusion on it this week.
> 
> Thanks. Any chance you can take a look at the U-Boot clock driver to patch it
> as per the DT changes ?

I probably won't have the chance to get to it for a while.  Looks like 
Anup was the one who posted the clock driver to U-Boot - can he take a 
look at it?

We've also asked Troy to look at upstream U-boot related issues, but 
I'm unsure when patches will start flowing upstream.


- Paul

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: 5.2-rc1 boot on Unleashed
  2019-05-22  9:58     ` Andreas Schwab
@ 2019-05-22 21:13       ` Paul Walmsley
  0 siblings, 0 replies; 42+ messages in thread
From: Paul Walmsley @ 2019-05-22 21:13 UTC (permalink / raw)
  To: Andreas Schwab
  Cc: Atish Patra, linux-riscv, Palmer Dabbelt, Björn Töpel

On Wed, 22 May 2019, Andreas Schwab wrote:

> What does that mean?
> 
> [    9.538450] of_fixed_factor_clk: probe of soc:tlclk failed with error -17

Most likely the PRCI driver isn't probing.  In mainline v5.2-rc1, that 
driver supplies tlclk - assuming it's been compiled in, and the DT data is 
aligned.

Likely causes could be that the PRCI driver wasn't compiled into the 
kernel, or the compatible string for the PRCI DT data doesn't match what 
the PRCI driver has in its match table.


- Paul

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: 5.2-rc1 boot on Unleashed
  2019-05-22 20:43     ` Paul Walmsley
@ 2019-05-22 22:14       ` Troy Benjegerdes
  2019-05-25  8:06         ` Anup Patel
  2019-05-24  0:23       ` Troy Benjegerdes
  1 sibling, 1 reply; 42+ messages in thread
From: Troy Benjegerdes @ 2019-05-22 22:14 UTC (permalink / raw)
  To: Paul Walmsley
  Cc: anup.patel, Atish Patra, linux-riscv, Palmer Dabbelt,
	Björn Töpel


> On May 22, 2019, at 3:43 PM, Paul Walmsley <paul.walmsley@sifive.com> wrote:
> 
> + Anup, Troy
> 
> On Wed, 22 May 2019, Atish Patra wrote:
> 
>> On 5/22/19 9:42 AM, Paul Walmsley wrote:
>>> Am checking on this now and hope to have some conclusion on it this week.
>> 
>> Thanks. Any chance you can take a look at the U-Boot clock driver to patch it
>> as per the DT changes ?
> 
> I probably won't have the chance to get to it for a while.  Looks like 
> Anup was the one who posted the clock driver to U-Boot - can he take a 
> look at it?
> 
> We've also asked Troy to look at upstream U-boot related issues, but 
> I'm unsure when patches will start flowing upstream.
> 
> 
> - Paul

Once I figure out why I’m getting TX timeouts on the macb driver and have something working I can start upstreaming the u-boot patches.

For now, the work-in-progress is at https://github.com/sifive/u-boot/tree/sandbox
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: 5.2-rc1 boot on Unleashed
  2019-05-21 18:18   ` Atish Patra
@ 2019-05-23  9:42     ` Andreas Schwab
  0 siblings, 0 replies; 42+ messages in thread
From: Andreas Schwab @ 2019-05-23  9:42 UTC (permalink / raw)
  To: Atish Patra
  Cc: Kevin Hilman, linux-riscv, Palmer Dabbelt, Björn Töpel,
	paul.walmsley

On Mai 21 2019, Atish Patra <atish.patra@wdc.com> wrote:

> On 5/21/19 10:48 AM, Kevin Hilman wrote:
>> Atish Patra <atish.patra@wdc.com> writes:
>>
>>> Hi,
>>>
>>> 5.2-rc1 still requires some out-of-tree driver patches.
>>>
>>> Here is my tree (successfully tested on Unleashed.)
>>> https://github.com/atishp04/linux/tree/5.2-rc1_unleashed
>>>
>>> Issues:
>>>
>>> 1. Thanks to Paul, uart & clock drivers are merged. However,
>>> 	a. upstream clock drivers require DT changes
>>> 	b. Those DT changes are still being reviewed.
>>> 	c. FSBL need to be rebuild & updated for these DT changes.
>>
>> I would also add that due to DT changes required:
>>
>>    d. Does not work with upstream u-boot
>>
>
> Yeah. I guess PRCI clock DT changes may not be backward compatible with
> U-Boot PRCI driver. Apart from FSBL update, we also need to patch U-Boot
> PRCI clock driver now.

Looks like it breaks the serial driver.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: 5.2-rc1 boot on Unleashed
  2019-05-22 20:43     ` Paul Walmsley
  2019-05-22 22:14       ` Troy Benjegerdes
@ 2019-05-24  0:23       ` Troy Benjegerdes
  2019-05-24  3:59         ` Atish Patra
  1 sibling, 1 reply; 42+ messages in thread
From: Troy Benjegerdes @ 2019-05-24  0:23 UTC (permalink / raw)
  To: Paul Walmsley
  Cc: anup.patel, Atish Patra, linux-riscv, Palmer Dabbelt,
	Björn Töpel



> On May 22, 2019, at 3:43 PM, Paul Walmsley <paul.walmsley@sifive.com> wrote:
> 
> + Anup, Troy
> 
> On Wed, 22 May 2019, Atish Patra wrote:
> 
>> On 5/22/19 9:42 AM, Paul Walmsley wrote:
>>> Am checking on this now and hope to have some conclusion on it this week.
>> 
>> Thanks. Any chance you can take a look at the U-Boot clock driver to patch it
>> as per the DT changes ?
> 
> I probably won't have the chance to get to it for a while.  Looks like 
> Anup was the one who posted the clock driver to U-Boot - can he take a 
> look at it?
> 
> We've also asked Troy to look at upstream U-boot related issues, but 
> I'm unsure when patches will start flowing upstream.
> 
> 
> - Paul


I’d prefer to hold off on any changes to U-boot until we have a more complete patch set. GPIO and ethernet entries are missing from those device trees, and we have a working U-boot device tree now. If the kernel needs something different we can load the device tree the kernel needs for awhile.

The U-boot device tree is going to have some things in it the kernel doesn’t care about anyway, so we’ve already got divergence between the two. Ideally the U-boot version is a superset of the kernel version. We already had one disruptive change with the clock driver, so what is to prevent there to be more disruptive changes in the ethernet/GPIO device tree entries that go in the kernel unless we have a draft of what those entries should look like that is acceptable?
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: 5.2-rc1 boot on Unleashed
  2019-05-24  0:23       ` Troy Benjegerdes
@ 2019-05-24  3:59         ` Atish Patra
  2019-05-24 14:46           ` Troy Benjegerdes
  0 siblings, 1 reply; 42+ messages in thread
From: Atish Patra @ 2019-05-24  3:59 UTC (permalink / raw)
  To: Troy Benjegerdes, Paul Walmsley
  Cc: Anup Patel, Björn Töpel, linux-riscv, Palmer Dabbelt

On 5/23/19 5:23 PM, Troy Benjegerdes wrote:
> 
> 
>> On May 22, 2019, at 3:43 PM, Paul Walmsley <paul.walmsley@sifive.com> wrote:
>>
>> + Anup, Troy
>>
>> On Wed, 22 May 2019, Atish Patra wrote:
>>
>>> On 5/22/19 9:42 AM, Paul Walmsley wrote:
>>>> Am checking on this now and hope to have some conclusion on it this week.
>>>
>>> Thanks. Any chance you can take a look at the U-Boot clock driver to patch it
>>> as per the DT changes ?
>>
>> I probably won't have the chance to get to it for a while.  Looks like
>> Anup was the one who posted the clock driver to U-Boot - can he take a
>> look at it?
>>
>> We've also asked Troy to look at upstream U-boot related issues, but
>> I'm unsure when patches will start flowing upstream.
>>
>>
>> - Paul
> 
> 
> I’d prefer to hold off on any changes to U-boot until we have a more complete patch set. GPIO and ethernet entries are missing from those device trees, and we have a working U-boot device tree now. If the kernel needs something different we can load the device tree the kernel needs for awhile.
> 

I don't think that's a good idea. It will unnecessarily block 
everybody's setup that is supposed to work with U-Boot. I prefer if we 
can patch U-Boot and unblock everybody sooner than later.

> The U-boot device tree is going to have some things in it the kernel doesn’t care about anyway, so we’ve already got divergence between the two. Ideally the U-boot version is a superset of the kernel version. We already had one disruptive change with the clock driver, so what is to prevent there to be more disruptive changes in the ethernet/GPIO device tree entries that go in the kernel unless we have a draft of what those entries should look like that is acceptable?
> 
IIRC, current U-Boot S mode port doesn't need a GPIO driver and ethernet 
driver is provided by the common macb driver. If there are any DT 
changes suggested by kernel, we can always patch U-Boot.

-- 
Regards,
Atish

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: 5.2-rc1 boot on Unleashed
  2019-05-24  3:59         ` Atish Patra
@ 2019-05-24 14:46           ` Troy Benjegerdes
  2019-05-24 15:35             ` Auer, Lukas
  2019-05-25 18:09             ` Paul Walmsley
  0 siblings, 2 replies; 42+ messages in thread
From: Troy Benjegerdes @ 2019-05-24 14:46 UTC (permalink / raw)
  To: Atish Patra
  Cc: Anup Patel, Björn Töpel, linux-riscv, Palmer Dabbelt,
	Paul Walmsley



> On May 23, 2019, at 10:59 PM, Atish Patra <atish.patra@wdc.com> wrote:
> 
> On 5/23/19 5:23 PM, Troy Benjegerdes wrote:
>>> On May 22, 2019, at 3:43 PM, Paul Walmsley <paul.walmsley@sifive.com> wrote:
>>> 
>>> + Anup, Troy
>>> 
>>> On Wed, 22 May 2019, Atish Patra wrote:
>>> 
>>>> On 5/22/19 9:42 AM, Paul Walmsley wrote:
>>>>> Am checking on this now and hope to have some conclusion on it this week.
>>>> 
>>>> Thanks. Any chance you can take a look at the U-Boot clock driver to patch it
>>>> as per the DT changes ?
>>> 
>>> I probably won't have the chance to get to it for a while.  Looks like
>>> Anup was the one who posted the clock driver to U-Boot - can he take a
>>> look at it?
>>> 
>>> We've also asked Troy to look at upstream U-boot related issues, but
>>> I'm unsure when patches will start flowing upstream.
>>> 
>>> 
>>> - Paul
>> I’d prefer to hold off on any changes to U-boot until we have a more complete patch set. GPIO and ethernet entries are missing from those device trees, and we have a working U-boot device tree now. If the kernel needs something different we can load the device tree the kernel needs for awhile.
> 
> I don't think that's a good idea. It will unnecessarily block everybody's setup that is supposed to work with U-Boot. I prefer if we can patch U-Boot and unblock everybody sooner than later.
> 
>> The U-boot device tree is going to have some things in it the kernel doesn’t care about anyway, so we’ve already got divergence between the two. Ideally the U-boot version is a superset of the kernel version. We already had one disruptive change with the clock driver, so what is to prevent there to be more disruptive changes in the ethernet/GPIO device tree entries that go in the kernel unless we have a draft of what those entries should look like that is acceptable?
> IIRC, current U-Boot S mode port doesn't need a GPIO driver and ethernet driver is provided by the common macb driver. If there are any DT changes suggested by kernel, we can always patch U-Boot.

The M-mode port will need a GPIO driver, as the macb driver needs proper a proper GPIO driver to reset the phy.

I have no issues updating the PRCI driver DT format if we also have the rest of the DT entries needed to boot a working system, I just have not seen an example of that other than what I have at https://github.com/sifive/HiFive_U-Boot/blob/regression/arch/riscv/dts/hifive_u540.dts
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: 5.2-rc1 boot on Unleashed
  2019-05-24 14:46           ` Troy Benjegerdes
@ 2019-05-24 15:35             ` Auer, Lukas
  2019-05-24 16:01               ` Troy Benjegerdes
  2019-05-25 18:09             ` Paul Walmsley
  1 sibling, 1 reply; 42+ messages in thread
From: Auer, Lukas @ 2019-05-24 15:35 UTC (permalink / raw)
  To: atish.patra, troy.benjegerdes
  Cc: Anup.Patel, bjorn.topel, linux-riscv, palmer, paul.walmsley

On Fri, 2019-05-24 at 09:46 -0500, Troy Benjegerdes wrote:
> > On May 23, 2019, at 10:59 PM, Atish Patra <atish.patra@wdc.com> wrote:
> > 
> > On 5/23/19 5:23 PM, Troy Benjegerdes wrote:
> > > > On May 22, 2019, at 3:43 PM, Paul Walmsley <paul.walmsley@sifive.com> wrote:
> > > > 
> > > > + Anup, Troy
> > > > 
> > > > On Wed, 22 May 2019, Atish Patra wrote:
> > > > 
> > > > > On 5/22/19 9:42 AM, Paul Walmsley wrote:
> > > > > > Am checking on this now and hope to have some conclusion on it this week.
> > > > > 
> > > > > Thanks. Any chance you can take a look at the U-Boot clock driver to patch it
> > > > > as per the DT changes ?
> > > > 
> > > > I probably won't have the chance to get to it for a while.  Looks like
> > > > Anup was the one who posted the clock driver to U-Boot - can he take a
> > > > look at it?
> > > > 
> > > > We've also asked Troy to look at upstream U-boot related issues, but
> > > > I'm unsure when patches will start flowing upstream.
> > > > 
> > > > 
> > > > - Paul
> > > I’d prefer to hold off on any changes to U-boot until we have a more complete patch set. GPIO and ethernet entries are missing from those device trees, and we have a working U-boot device tree now. If the kernel needs something different we can load the device tree the kernel needs for awhile.
> > 
> > I don't think that's a good idea. It will unnecessarily block everybody's setup that is supposed to work with U-Boot. I prefer if we can patch U-Boot and unblock everybody sooner than later.
> > 
> > > The U-boot device tree is going to have some things in it the kernel doesn’t care about anyway, so we’ve already got divergence between the two. Ideally the U-boot version is a superset of the kernel version. We already had one disruptive change with the clock driver, so what is to prevent there to be more disruptive changes in the ethernet/GPIO device tree entries that go in the kernel unless we have a draft of what those entries should look like that is acceptable?
> > IIRC, current U-Boot S mode port doesn't need a GPIO driver and ethernet driver is provided by the common macb driver. If there are any DT changes suggested by kernel, we can always patch U-Boot.
> 
> The M-mode port will need a GPIO driver, as the macb driver needs proper a proper GPIO driver to reset the phy.
> 
> I have no issues updating the PRCI driver DT format if we also have the rest of the DT entries needed to boot a working system, I just have not seen an example of that other than what I have at https://github.com/sifive/HiFive_U-Boot/blob/regression/arch/riscv/dts/hifive_u540.dts

My plan was to add the SiFive HiFive Unleashed device tree to U-Boot,
once the relevant kernel patches with the device tree get merged. I
would keep both identical to make it easier to sync changes from the
kernel with U-Boot.

Thanks,
Lukas
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: 5.2-rc1 boot on Unleashed
  2019-05-24 15:35             ` Auer, Lukas
@ 2019-05-24 16:01               ` Troy Benjegerdes
  2019-05-24 17:40                 ` Atish Patra
  0 siblings, 1 reply; 42+ messages in thread
From: Troy Benjegerdes @ 2019-05-24 16:01 UTC (permalink / raw)
  To: Auer, Lukas
  Cc: palmer, bjorn.topel, Anup.Patel, atish.patra, Jim Jacobsen,
	paul.walmsley, linux-riscv, Jeffery Carr



> On May 24, 2019, at 10:35 AM, Auer, Lukas <lukas.auer@aisec.fraunhofer.de> wrote:
> 
> On Fri, 2019-05-24 at 09:46 -0500, Troy Benjegerdes wrote:
>>> On May 23, 2019, at 10:59 PM, Atish Patra <atish.patra@wdc.com> wrote:
>>> 
>>> On 5/23/19 5:23 PM, Troy Benjegerdes wrote:
>>>>> On May 22, 2019, at 3:43 PM, Paul Walmsley <paul.walmsley@sifive.com> wrote:
>>>>> 
>>>>> + Anup, Troy
>>>>> 
>>>>> On Wed, 22 May 2019, Atish Patra wrote:
>>>>> 
>>>>>> On 5/22/19 9:42 AM, Paul Walmsley wrote:
>>>>>>> Am checking on this now and hope to have some conclusion on it this week.
>>>>>> 
>>>>>> Thanks. Any chance you can take a look at the U-Boot clock driver to patch it
>>>>>> as per the DT changes ?
>>>>> 
>>>>> I probably won't have the chance to get to it for a while.  Looks like
>>>>> Anup was the one who posted the clock driver to U-Boot - can he take a
>>>>> look at it?
>>>>> 
>>>>> We've also asked Troy to look at upstream U-boot related issues, but
>>>>> I'm unsure when patches will start flowing upstream.
>>>>> 
>>>>> 
>>>>> - Paul
>>>> I’d prefer to hold off on any changes to U-boot until we have a more complete patch set. GPIO and ethernet entries are missing from those device trees, and we have a working U-boot device tree now. If the kernel needs something different we can load the device tree the kernel needs for awhile.
>>> 
>>> I don't think that's a good idea. It will unnecessarily block everybody's setup that is supposed to work with U-Boot. I prefer if we can patch U-Boot and unblock everybody sooner than later.
>>> 
>>>> The U-boot device tree is going to have some things in it the kernel doesn’t care about anyway, so we’ve already got divergence between the two. Ideally the U-boot version is a superset of the kernel version. We already had one disruptive change with the clock driver, so what is to prevent there to be more disruptive changes in the ethernet/GPIO device tree entries that go in the kernel unless we have a draft of what those entries should look like that is acceptable?
>>> IIRC, current U-Boot S mode port doesn't need a GPIO driver and ethernet driver is provided by the common macb driver. If there are any DT changes suggested by kernel, we can always patch U-Boot.
>> 
>> The M-mode port will need a GPIO driver, as the macb driver needs proper a proper GPIO driver to reset the phy.
>> 
>> I have no issues updating the PRCI driver DT format if we also have the rest of the DT entries needed to boot a working system, I just have not seen an example of that other than what I have at https://github.com/sifive/HiFive_U-Boot/blob/regression/arch/riscv/dts/hifive_u540.dts
> 
> My plan was to add the SiFive HiFive Unleashed device tree to U-Boot,
> once the relevant kernel patches with the device tree get merged. I
> would keep both identical to make it easier to sync changes from the
> kernel with U-Boot.
> 
> Thanks,
> Lukas

We need to support Uboot in M-mode as the first-stage bootloader, and this will require DDR init code. The best way to do that seems to be follow the example that was used for a Rockchip part with a similiar DDR controller IP. The DDR init code uses board-specific data from the device tree to program the controller, so the M-mode Uboot will need to have entries the kernel doesn’t care about.

If we are going to keep both U-boot and Kernel device trees identical then we need some buy-in and agreement from kernel developers on how that data goes in the kernel.

It seems a lot easier if we use include files and the U-boot device tree has a few extra includes for DDR init and other things that are not relevant to the kernel.
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: 5.2-rc1 boot on Unleashed
  2019-05-24 16:01               ` Troy Benjegerdes
@ 2019-05-24 17:40                 ` Atish Patra
       [not found]                   ` <CAF5mof3_PSwpsSMnjMALpfvmOPdeAgDLa2p6jp4y+Hmas83mbw@mail.gmail.com>
  0 siblings, 1 reply; 42+ messages in thread
From: Atish Patra @ 2019-05-24 17:40 UTC (permalink / raw)
  To: Troy Benjegerdes, Auer, Lukas
  Cc: palmer, bjorn.topel, Anup Patel, paul.walmsley, Jim Jacobsen,
	linux-riscv, Jeffery Carr

On 5/24/19 9:01 AM, Troy Benjegerdes wrote:
> 
> 
>> On May 24, 2019, at 10:35 AM, Auer, Lukas <lukas.auer@aisec.fraunhofer.de> wrote:
>>
>> On Fri, 2019-05-24 at 09:46 -0500, Troy Benjegerdes wrote:
>>>> On May 23, 2019, at 10:59 PM, Atish Patra <atish.patra@wdc.com> wrote:
>>>>
>>>> On 5/23/19 5:23 PM, Troy Benjegerdes wrote:
>>>>>> On May 22, 2019, at 3:43 PM, Paul Walmsley <paul.walmsley@sifive.com> wrote:
>>>>>>
>>>>>> + Anup, Troy
>>>>>>
>>>>>> On Wed, 22 May 2019, Atish Patra wrote:
>>>>>>
>>>>>>> On 5/22/19 9:42 AM, Paul Walmsley wrote:
>>>>>>>> Am checking on this now and hope to have some conclusion on it this week.
>>>>>>>
>>>>>>> Thanks. Any chance you can take a look at the U-Boot clock driver to patch it
>>>>>>> as per the DT changes ?
>>>>>>
>>>>>> I probably won't have the chance to get to it for a while.  Looks like
>>>>>> Anup was the one who posted the clock driver to U-Boot - can he take a
>>>>>> look at it?
>>>>>>
>>>>>> We've also asked Troy to look at upstream U-boot related issues, but
>>>>>> I'm unsure when patches will start flowing upstream.
>>>>>>
>>>>>>
>>>>>> - Paul
>>>>> I’d prefer to hold off on any changes to U-boot until we have a more complete patch set. GPIO and ethernet entries are missing from those device trees, and we have a working U-boot device tree now. If the kernel needs something different we can load the device tree the kernel needs for awhile.
>>>>
>>>> I don't think that's a good idea. It will unnecessarily block everybody's setup that is supposed to work with U-Boot. I prefer if we can patch U-Boot and unblock everybody sooner than later.
>>>>
>>>>> The U-boot device tree is going to have some things in it the kernel doesn’t care about anyway, so we’ve already got divergence between the two. Ideally the U-boot version is a superset of the kernel version. We already had one disruptive change with the clock driver, so what is to prevent there to be more disruptive changes in the ethernet/GPIO device tree entries that go in the kernel unless we have a draft of what those entries should look like that is acceptable?
>>>> IIRC, current U-Boot S mode port doesn't need a GPIO driver and ethernet driver is provided by the common macb driver. If there are any DT changes suggested by kernel, we can always patch U-Boot.
>>>
>>> The M-mode port will need a GPIO driver, as the macb driver needs proper a proper GPIO driver to reset the phy.
>>>
>>> I have no issues updating the PRCI driver DT format if we also have the rest of the DT entries needed to boot a working system, I just have not seen an example of that other than what I have at https://github.com/sifive/HiFive_U-Boot/blob/regression/arch/riscv/dts/hifive_u540.dts
>>
>> My plan was to add the SiFive HiFive Unleashed device tree to U-Boot,
>> once the relevant kernel patches with the device tree get merged. I
>> would keep both identical to make it easier to sync changes from the
>> kernel with U-Boot.
>>

That makes sense.

>> Thanks,
>> Lukas
> 
> We need to support Uboot in M-mode as the first-stage bootloader, 

Great. We will have following boot flow in that case.

U-Boot (M-Mode)->OpenSBI/BBL->U-Boot(S-Mode)->Linux.

I am more concerned about breakage and patching of U-Boot S mode at this 
point.

and this will require DDR init code. The best way to do that seems to be 
follow the example that was used for a Rockchip part with a similiar DDR 
controller IP. The DDR init code uses board-specific data from the 
device tree to program the controller, so the M-mode Uboot will need to 
have entries the kernel doesn’t care about.
> 
> If we are going to keep both U-boot and Kernel device trees identical then we need some buy-in and agreement from kernel developers on how that data goes in the kernel.
> 
> It seems a lot easier if we use include files and the U-boot device tree has a few extra includes for DDR init and other things that are not relevant to the kernel.
> 


-- 
Regards,
Atish

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: 5.2-rc1 boot on Unleashed
       [not found]                   ` <CAF5mof3_PSwpsSMnjMALpfvmOPdeAgDLa2p6jp4y+Hmas83mbw@mail.gmail.com>
@ 2019-05-24 21:34                     ` Auer, Lukas
  2019-05-25  3:49                       ` Anup Patel
  0 siblings, 1 reply; 42+ messages in thread
From: Auer, Lukas @ 2019-05-24 21:34 UTC (permalink / raw)
  To: Atish.Patra, troy.benjegerdes
  Cc: palmer, jamez, Anup.Patel, paul.walmsley, bjorn.topel,
	linux-riscv, jcarr

On Fri, 2019-05-24 at 13:48 -0500, Troy Benjegerdes wrote:
> Would a reasonable answer be two device trees, one for M-mode and another for S-mode?
> 
> This would let us easily keep synced with the kernel version
> 

That makes sense, I wasn't aware of the DDR init data in the device
tree. It's great to see that you are working on adding support for the
DDR controller to U-Boot!

That would work, but probably takes more effort to maintain than is
needed. For situations like this, where the U-Boot device tree requires
a few additional entries compared with the kernel device tree, U-Boot
provides a useful function. It automatically includes [board-dts]-u-
boot.dtsi in the compiled device tree, where [board-dts].dts is
specified in the defconfig. In this case, we can directly use hifive-
unleashed-a00-fu540.dts from the kernel and add a hifive-unleashed-a00-
fu540-u-boot.dtsi with the DDR controller entries. Since they are only
needed in machine mode, we can use ifdefs to remove them in supervisor
mode builds.

Thanks,
Lukas

> On Fri, May 24, 2019, 12:40 PM Atish Patra <atish.patra@wdc.com> wrote:
> > On 5/24/19 9:01 AM, Troy Benjegerdes wrote:
> > > 
> > > 
> > >> On May 24, 2019, at 10:35 AM, Auer, Lukas <lukas.auer@aisec.fraunhofer.de> wrote:
> > >>
> > >> On Fri, 2019-05-24 at 09:46 -0500, Troy Benjegerdes wrote:
> > >>>> On May 23, 2019, at 10:59 PM, Atish Patra <atish.patra@wdc.com> wrote:
> > >>>>
> > >>>> On 5/23/19 5:23 PM, Troy Benjegerdes wrote:
> > >>>>>> On May 22, 2019, at 3:43 PM, Paul Walmsley <paul.walmsley@sifive.com> wrote:
> > >>>>>>
> > >>>>>> + Anup, Troy
> > >>>>>>
> > >>>>>> On Wed, 22 May 2019, Atish Patra wrote:
> > >>>>>>
> > >>>>>>> On 5/22/19 9:42 AM, Paul Walmsley wrote:
> > >>>>>>>> Am checking on this now and hope to have some conclusion on it this week.
> > >>>>>>>
> > >>>>>>> Thanks. Any chance you can take a look at the U-Boot clock driver to patch it
> > >>>>>>> as per the DT changes ?
> > >>>>>>
> > >>>>>> I probably won't have the chance to get to it for a while.  Looks like
> > >>>>>> Anup was the one who posted the clock driver to U-Boot - can he take a
> > >>>>>> look at it?
> > >>>>>>
> > >>>>>> We've also asked Troy to look at upstream U-boot related issues, but
> > >>>>>> I'm unsure when patches will start flowing upstream.
> > >>>>>>
> > >>>>>>
> > >>>>>> - Paul
> > >>>>> I’d prefer to hold off on any changes to U-boot until we have a more complete patch set. GPIO and ethernet entries are missing from those device trees, and we have a working U-boot device tree now. If the kernel needs something different we can load the device tree the kernel needs for awhile.
> > >>>>
> > >>>> I don't think that's a good idea. It will unnecessarily block everybody's setup that is supposed to work with U-Boot. I prefer if we can patch U-Boot and unblock everybody sooner than later.
> > >>>>
> > >>>>> The U-boot device tree is going to have some things in it the kernel doesn’t care about anyway, so we’ve already got divergence between the two. Ideally the U-boot version is a superset of the kernel version. We already had one disruptive change with the clock driver, so what is to prevent there to be more disruptive changes in the ethernet/GPIO device tree entries that go in the kernel unless we have a draft of what those entries should look like that is acceptable?
> > >>>> IIRC, current U-Boot S mode port doesn't need a GPIO driver and ethernet driver is provided by the common macb driver. If there are any DT changes suggested by kernel, we can always patch U-Boot.
> > >>>
> > >>> The M-mode port will need a GPIO driver, as the macb driver needs proper a proper GPIO driver to reset the phy.
> > >>>
> > >>> I have no issues updating the PRCI driver DT format if we also have the rest of the DT entries needed to boot a working system, I just have not seen an example of that other than what I have at https://github.com/sifive/HiFive_U-Boot/blob/regression/arch/riscv/dts/hifive_u540.dts
> > >>
> > >> My plan was to add the SiFive HiFive Unleashed device tree to U-Boot,
> > >> once the relevant kernel patches with the device tree get merged. I
> > >> would keep both identical to make it easier to sync changes from the
> > >> kernel with U-Boot.
> > >>
> > 
> > That makes sense.
> > 
> > >> Thanks,
> > >> Lukas
> > > 
> > > We need to support Uboot in M-mode as the first-stage bootloader, 
> > 
> > Great. We will have following boot flow in that case.
> > 
> > U-Boot (M-Mode)->OpenSBI/BBL->U-Boot(S-Mode)->Linux.
> > 
> > I am more concerned about breakage and patching of U-Boot S mode at this 
> > point.
> > 
> > and this will require DDR init code. The best way to do that seems to be 
> > follow the example that was used for a Rockchip part with a similiar DDR 
> > controller IP. The DDR init code uses board-specific data from the 
> > device tree to program the controller, so the M-mode Uboot will need to 
> > have entries the kernel doesn’t care about.
> > > 
> > > If we are going to keep both U-boot and Kernel device trees identical then we need some buy-in and agreement from kernel developers on how that data goes in the kernel.
> > > 
> > > It seems a lot easier if we use include files and the U-boot device tree has a few extra includes for DDR init and other things that are not relevant to the kernel.
> > > 
> > 
> > 
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 42+ messages in thread

* RE: 5.2-rc1 boot on Unleashed
  2019-05-24 21:34                     ` Auer, Lukas
@ 2019-05-25  3:49                       ` Anup Patel
  2019-05-25 16:23                         ` Troy Benjegerdes
  0 siblings, 1 reply; 42+ messages in thread
From: Anup Patel @ 2019-05-25  3:49 UTC (permalink / raw)
  To: Auer, Lukas, Atish Patra, troy.benjegerdes
  Cc: jamez, palmer, paul.walmsley, bjorn.topel, linux-riscv, jcarr



> -----Original Message-----
> From: Auer, Lukas <lukas.auer@aisec.fraunhofer.de>
> Sent: Saturday, May 25, 2019 3:05 AM
> To: Atish Patra <Atish.Patra@wdc.com>; troy.benjegerdes@sifive.com
> Cc: paul.walmsley@sifive.com; linux-riscv@lists.infradead.org;
> jamez@wit.com; palmer@sifive.com; Anup Patel <Anup.Patel@wdc.com>;
> bjorn.topel@gmail.com; jcarr@wit.com
> Subject: Re: 5.2-rc1 boot on Unleashed
> 
> On Fri, 2019-05-24 at 13:48 -0500, Troy Benjegerdes wrote:
> > Would a reasonable answer be two device trees, one for M-mode and
> another for S-mode?
> >
> > This would let us easily keep synced with the kernel version
> >
> 
> That makes sense, I wasn't aware of the DDR init data in the device tree. It's
> great to see that you are working on adding support for the DDR controller to
> U-Boot!
> 
> That would work, but probably takes more effort to maintain than is needed.
> For situations like this, where the U-Boot device tree requires a few
> additional entries compared with the kernel device tree, U-Boot provides a
> useful function. It automatically includes [board-dts]-u- boot.dtsi in the
> compiled device tree, where [board-dts].dts is specified in the defconfig. In
> this case, we can directly use hifive- unleashed-a00-fu540.dts from the
> kernel and add a hifive-unleashed-a00- fu540-u-boot.dtsi with the DDR
> controller entries. Since they are only needed in machine mode, we can use
> ifdefs to remove them in supervisor mode builds.

Based on our previous discussion on U-Boot mailing list, Lukas had suggest
very nice boot-flow for U-Boot which is as follows:

ZSBL -> U-Boot SPL (M-Mode)->OpenSBI/BBL->U-Boot(S-Mode)->Linux.

The U-Boot SPL above will:
1. Run from internal SRAM
2. Will do DDR init
3. Ethernet PHY reset using GPIO
4. Other system level init.
5. Load OpenSBI FW_DYNAMIC/FW_JUMP/FW_PAYLOAD
6. Load U-Boot S-mode
7. Jump to OpenSBI FW_DYNAMIC/FW_FUMP/FW_PAYLOAD

The regular S-mode U-Boot can be re-used as-is without much changes.

Overall using U-Boot SPL (M-mode) as-per above will be a natural extension
of current U-Boot for SiFive Unleashed.

Regards,
Anup

> 
> Thanks,
> Lukas
> 
> > On Fri, May 24, 2019, 12:40 PM Atish Patra <atish.patra@wdc.com> wrote:
> > > On 5/24/19 9:01 AM, Troy Benjegerdes wrote:
> > > >
> > > >
> > > >> On May 24, 2019, at 10:35 AM, Auer, Lukas
> <lukas.auer@aisec.fraunhofer.de> wrote:
> > > >>
> > > >> On Fri, 2019-05-24 at 09:46 -0500, Troy Benjegerdes wrote:
> > > >>>> On May 23, 2019, at 10:59 PM, Atish Patra <atish.patra@wdc.com>
> wrote:
> > > >>>>
> > > >>>> On 5/23/19 5:23 PM, Troy Benjegerdes wrote:
> > > >>>>>> On May 22, 2019, at 3:43 PM, Paul Walmsley
> <paul.walmsley@sifive.com> wrote:
> > > >>>>>>
> > > >>>>>> + Anup, Troy
> > > >>>>>>
> > > >>>>>> On Wed, 22 May 2019, Atish Patra wrote:
> > > >>>>>>
> > > >>>>>>> On 5/22/19 9:42 AM, Paul Walmsley wrote:
> > > >>>>>>>> Am checking on this now and hope to have some conclusion
> on it this week.
> > > >>>>>>>
> > > >>>>>>> Thanks. Any chance you can take a look at the U-Boot clock
> > > >>>>>>> driver to patch it as per the DT changes ?
> > > >>>>>>
> > > >>>>>> I probably won't have the chance to get to it for a while.
> > > >>>>>> Looks like Anup was the one who posted the clock driver to
> > > >>>>>> U-Boot - can he take a look at it?
> > > >>>>>>
> > > >>>>>> We've also asked Troy to look at upstream U-boot related
> > > >>>>>> issues, but I'm unsure when patches will start flowing upstream.
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> - Paul
> > > >>>>> I’d prefer to hold off on any changes to U-boot until we have a
> more complete patch set. GPIO and ethernet entries are missing from those
> device trees, and we have a working U-boot device tree now. If the kernel
> needs something different we can load the device tree the kernel needs for
> awhile.
> > > >>>>
> > > >>>> I don't think that's a good idea. It will unnecessarily block
> everybody's setup that is supposed to work with U-Boot. I prefer if we can
> patch U-Boot and unblock everybody sooner than later.
> > > >>>>
> > > >>>>> The U-boot device tree is going to have some things in it the
> kernel doesn’t care about anyway, so we’ve already got divergence between
> the two. Ideally the U-boot version is a superset of the kernel version. We
> already had one disruptive change with the clock driver, so what is to prevent
> there to be more disruptive changes in the ethernet/GPIO device tree
> entries that go in the kernel unless we have a draft of what those entries
> should look like that is acceptable?
> > > >>>> IIRC, current U-Boot S mode port doesn't need a GPIO driver and
> ethernet driver is provided by the common macb driver. If there are any DT
> changes suggested by kernel, we can always patch U-Boot.
> > > >>>
> > > >>> The M-mode port will need a GPIO driver, as the macb driver needs
> proper a proper GPIO driver to reset the phy.
> > > >>>
> > > >>> I have no issues updating the PRCI driver DT format if we also
> > > >>> have the rest of the DT entries needed to boot a working system,
> > > >>> I just have not seen an example of that other than what I have
> > > >>> at
> > > >>> https://github.com/sifive/HiFive_U-Boot/blob/regression/arch/ris
> > > >>> cv/dts/hifive_u540.dts
> > > >>
> > > >> My plan was to add the SiFive HiFive Unleashed device tree to
> > > >> U-Boot, once the relevant kernel patches with the device tree get
> > > >> merged. I would keep both identical to make it easier to sync
> > > >> changes from the kernel with U-Boot.
> > > >>
> > >
> > > That makes sense.
> > >
> > > >> Thanks,
> > > >> Lukas
> > > >
> > > > We need to support Uboot in M-mode as the first-stage bootloader,
> > >
> > > Great. We will have following boot flow in that case.
> > >
> > > U-Boot (M-Mode)->OpenSBI/BBL->U-Boot(S-Mode)->Linux.
> > >
> > > I am more concerned about breakage and patching of U-Boot S mode at
> > > this point.
> > >
> > > and this will require DDR init code. The best way to do that seems
> > > to be follow the example that was used for a Rockchip part with a
> > > similiar DDR controller IP. The DDR init code uses board-specific
> > > data from the device tree to program the controller, so the M-mode
> > > Uboot will need to have entries the kernel doesn’t care about.
> > > >
> > > > If we are going to keep both U-boot and Kernel device trees identical
> then we need some buy-in and agreement from kernel developers on how
> that data goes in the kernel.
> > > >
> > > > It seems a lot easier if we use include files and the U-boot device tree
> has a few extra includes for DDR init and other things that are not relevant to
> the kernel.
> > > >
> > >
> > >
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: 5.2-rc1 boot on Unleashed
  2019-05-22 22:14       ` Troy Benjegerdes
@ 2019-05-25  8:06         ` Anup Patel
  2019-05-25 14:16           ` Troy Benjegerdes
  0 siblings, 1 reply; 42+ messages in thread
From: Anup Patel @ 2019-05-25  8:06 UTC (permalink / raw)
  To: Troy Benjegerdes
  Cc: Palmer Dabbelt, Björn Töpel, Anup Patel, Atish Patra,
	Lukas Auer, Paul Walmsley, linux-riscv, Bin Meng

Hi Troy,

On Thu, May 23, 2019 at 3:45 AM Troy Benjegerdes
<troy.benjegerdes@sifive.com> wrote:
>
>
> > On May 22, 2019, at 3:43 PM, Paul Walmsley <paul.walmsley@sifive.com> wrote:
> >
> > + Anup, Troy
> >
> > On Wed, 22 May 2019, Atish Patra wrote:
> >
> >> On 5/22/19 9:42 AM, Paul Walmsley wrote:
> >>> Am checking on this now and hope to have some conclusion on it this week.
> >>
> >> Thanks. Any chance you can take a look at the U-Boot clock driver to patch it
> >> as per the DT changes ?
> >
> > I probably won't have the chance to get to it for a while.  Looks like
> > Anup was the one who posted the clock driver to U-Boot - can he take a
> > look at it?
> >
> > We've also asked Troy to look at upstream U-boot related issues, but
> > I'm unsure when patches will start flowing upstream.
> >
> >
> > - Paul
>
> Once I figure out why I’m getting TX timeouts on the macb driver and have something working I can start upstreaming the u-boot patches.
>
> For now, the work-in-progress is at https://github.com/sifive/u-boot/tree/sandbox

Based on your commits in above GitRepo, it seems you are trying entire
U-Boot in M-mode.

Current boot-flow of S-mode U-Boot is:
ZSBL (M-mode) -> FSBL (M-mode) -> OpenSBI/BBL (M-mode) -> U-Boot (S-mode)

The U-Boot SPL can perfectly replace SiFive FSBL to have following
boot-flow:
ZSBL (M-mode) -> U-Boot SPL (M-mode) -> OpenSBI/BBL (M-mode) -> U-Boot (S-mode)

Can you explain advantages of using full U-Boot M-mode to replace
FSBL as compared to U-Boot SPL M-mode replacing FSBL ?

Regards,
Anup

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: 5.2-rc1 boot on Unleashed
  2019-05-25  8:06         ` Anup Patel
@ 2019-05-25 14:16           ` Troy Benjegerdes
  2019-05-29  5:00             ` Anup Patel
  0 siblings, 1 reply; 42+ messages in thread
From: Troy Benjegerdes @ 2019-05-25 14:16 UTC (permalink / raw)
  To: Anup Patel
  Cc: Palmer Dabbelt, Björn Töpel, Anup Patel, Atish Patra,
	Lukas Auer, Paul Walmsley, linux-riscv, Bin Meng



> On May 25, 2019, at 3:06 AM, Anup Patel <anup@brainfault.org> wrote:
> 
> Hi Troy,
> 
> On Thu, May 23, 2019 at 3:45 AM Troy Benjegerdes
> <troy.benjegerdes@sifive.com> wrote:
>> 
>> 
>>> On May 22, 2019, at 3:43 PM, Paul Walmsley <paul.walmsley@sifive.com> wrote:
>>> 
>>> + Anup, Troy
>>> 
>>> On Wed, 22 May 2019, Atish Patra wrote:
>>> 
>>>> On 5/22/19 9:42 AM, Paul Walmsley wrote:
>>>>> Am checking on this now and hope to have some conclusion on it this week.
>>>> 
>>>> Thanks. Any chance you can take a look at the U-Boot clock driver to patch it
>>>> as per the DT changes ?
>>> 
>>> I probably won't have the chance to get to it for a while.  Looks like
>>> Anup was the one who posted the clock driver to U-Boot - can he take a
>>> look at it?
>>> 
>>> We've also asked Troy to look at upstream U-boot related issues, but
>>> I'm unsure when patches will start flowing upstream.
>>> 
>>> 
>>> - Paul
>> 
>> Once I figure out why I’m getting TX timeouts on the macb driver and have something working I can start upstreaming the u-boot patches.
>> 
>> For now, the work-in-progress is at https://github.com/sifive/u-boot/tree/sandbox
> 
> Based on your commits in above GitRepo, it seems you are trying entire
> U-Boot in M-mode.
> 
> Current boot-flow of S-mode U-Boot is:
> ZSBL (M-mode) -> FSBL (M-mode) -> OpenSBI/BBL (M-mode) -> U-Boot (S-mode)
> 
> The U-Boot SPL can perfectly replace SiFive FSBL to have following
> boot-flow:
> ZSBL (M-mode) -> U-Boot SPL (M-mode) -> OpenSBI/BBL (M-mode) -> U-Boot (S-mode)
> 
> Can you explain advantages of using full U-Boot M-mode to replace
> FSBL as compared to U-Boot SPL M-mode replacing FSBL ?
> 
> Regards,
> Anup

The current flow in Freedom-u-sdk (with https://github.com/sifive/HiFive_U-Boot) is this:
ZSBL (M-mode) -> U-Boot (M-mode) -> BBL -> Linux kernel

The major driver for full U-Boot M-mode is automated regression testing and being able
to load the SBI interface (BBL or OpenSBI) and linux kernel via TFTP.

I do agree U-Boot SPL is a very good idea, I have been working on replicating the
functionality of the old HiFive U-boot first and then once that works I think it will be a
lot easier to work out the SPL option.


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: 5.2-rc1 boot on Unleashed
  2019-05-25  3:49                       ` Anup Patel
@ 2019-05-25 16:23                         ` Troy Benjegerdes
  0 siblings, 0 replies; 42+ messages in thread
From: Troy Benjegerdes @ 2019-05-25 16:23 UTC (permalink / raw)
  To: Anup Patel
  Cc: jamez, palmer, Atish Patra, Auer, Lukas, paul.walmsley,
	linux-riscv, jcarr, bjorn.topel



> On May 24, 2019, at 10:49 PM, Anup Patel <Anup.Patel@wdc.com> wrote:
> 
> 
> 
>> -----Original Message-----
>> From: Auer, Lukas <lukas.auer@aisec.fraunhofer.de>
>> Sent: Saturday, May 25, 2019 3:05 AM
>> To: Atish Patra <Atish.Patra@wdc.com>; troy.benjegerdes@sifive.com
>> Cc: paul.walmsley@sifive.com; linux-riscv@lists.infradead.org;
>> jamez@wit.com; palmer@sifive.com; Anup Patel <Anup.Patel@wdc.com>;
>> bjorn.topel@gmail.com; jcarr@wit.com
>> Subject: Re: 5.2-rc1 boot on Unleashed
>> 
>> On Fri, 2019-05-24 at 13:48 -0500, Troy Benjegerdes wrote:
>>> Would a reasonable answer be two device trees, one for M-mode and
>> another for S-mode?
>>> 
>>> This would let us easily keep synced with the kernel version
>>> 
>> 
>> That makes sense, I wasn't aware of the DDR init data in the device tree. It's
>> great to see that you are working on adding support for the DDR controller to
>> U-Boot!
>> 
>> That would work, but probably takes more effort to maintain than is needed.
>> For situations like this, where the U-Boot device tree requires a few
>> additional entries compared with the kernel device tree, U-Boot provides a
>> useful function. It automatically includes [board-dts]-u- boot.dtsi in the
>> compiled device tree, where [board-dts].dts is specified in the defconfig. In
>> this case, we can directly use hifive- unleashed-a00-fu540.dts from the
>> kernel and add a hifive-unleashed-a00- fu540-u-boot.dtsi with the DDR
>> controller entries. Since they are only needed in machine mode, we can use
>> ifdefs to remove them in supervisor mode builds.
> 
> Based on our previous discussion on U-Boot mailing list, Lukas had suggest
> very nice boot-flow for U-Boot which is as follows:
> 
> ZSBL -> U-Boot SPL (M-Mode)->OpenSBI/BBL->U-Boot(S-Mode)->Linux.
> 
> The U-Boot SPL above will:
> 1. Run from internal SRAM
> 2. Will do DDR init
> 3. Ethernet PHY reset using GPIO

Right now I am able do all of the above (although without a proper GPIO driver) 

What I’d like to get working before submitting patches is loading BBL/OpenSBI and a payload
(either the kernel directly, or U-boot(S-Mode) via TFTP. I suspect some kind of issue with
the ring buffer being in SRAM and/or a clocking init problem, as this is what I get:

U-Boot 2019.07-rc2-00202-g814bfda9a6 (May 24 2019 - 10:24:26 -0500)

CPU:   rv64imac
DRAM:  dram_init() start
dram_init() end
8 GiB
MMC:   
In:    serial
Out:   serial
Err:   serial
Net:   eth0: ethernet@10090000
Hit any key to stop autoboot:  0 
ethernet@10090000: PHY present at 0
ethernet@10090000: Starting autonegotiation...
ethernet@10090000: Autonegotiation complete
ethernet@10090000: link up, 1000Mbps full-duplex (lpa: 0x7800)
BOOTP broadcast 1
ethernet@10090000: TX timeout


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: 5.2-rc1 boot on Unleashed
  2019-05-24 14:46           ` Troy Benjegerdes
  2019-05-24 15:35             ` Auer, Lukas
@ 2019-05-25 18:09             ` Paul Walmsley
  2019-05-25 18:40               ` Troy Benjegerdes
  1 sibling, 1 reply; 42+ messages in thread
From: Paul Walmsley @ 2019-05-25 18:09 UTC (permalink / raw)
  To: Troy Benjegerdes
  Cc: Anup Patel, Atish Patra, linux-riscv, Palmer Dabbelt,
	Björn Töpel

On Fri, 24 May 2019, Troy Benjegerdes wrote:

> I have no issues updating the PRCI driver DT format if we also have the 
> rest of the DT entries needed to boot a working system

Now is the time to fix the U-boot PRCI issue upstream.  Fixing that should 
be straightforward, and should be enough to boot the system with initramfs 
and a serial console.  The missing patch is currently blocking others from 
using U-boot-based boot flows on Aloe.

> I just have not seen an example of that other than what I have at 
> https://github.com/sifive/HiFive_U-Boot/blob/regression/arch/riscv/dts/hifive_u540.dts

I sent you a pointer to a branch a few days ago that contains the most 
recent mainline-bound DTS data.  That should be enough to verify that the 
basic boot works.  If you want to keep up with the ongoing development of 
that data, the best bet is to subscribe to the linux-riscv mailing list.


- Paul

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: 5.2-rc1 boot on Unleashed
  2019-05-25 18:09             ` Paul Walmsley
@ 2019-05-25 18:40               ` Troy Benjegerdes
  2019-05-27 12:21                 ` Andreas Schwab
  0 siblings, 1 reply; 42+ messages in thread
From: Troy Benjegerdes @ 2019-05-25 18:40 UTC (permalink / raw)
  To: Paul Walmsley, Yash Shah
  Cc: Anup Patel, Atish Patra, linux-riscv, Palmer Dabbelt,
	Björn Töpel



> On May 25, 2019, at 1:09 PM, Paul Walmsley <paul.walmsley@sifive.com> wrote:
> 
> On Fri, 24 May 2019, Troy Benjegerdes wrote:
> 
>> I have no issues updating the PRCI driver DT format if we also have the 
>> rest of the DT entries needed to boot a working system
> 
> Now is the time to fix the U-boot PRCI issue upstream.  Fixing that should 
> be straightforward, and should be enough to boot the system with initramfs 
> and a serial console.  The missing patch is currently blocking others from 
> using U-boot-based boot flows on Aloe.

I suppose we have different opinions on what’s blocking what. 

If https://github.com/sifive/HiFive_U-Boot is not sufficient for U-boot based
development flows, I’d like to hear what it would need to be useful until I
have a full patch set for upstream U-boot that includes mainline-bound DTS
entries that can replicate the functionality the existing legacy u-boot port
has.

>> I just have not seen an example of that other than what I have at 
>> https://github.com/sifive/HiFive_U-Boot/blob/regression/arch/riscv/dts/hifive_u540.dts
> 
> I sent you a pointer to a branch a few days ago that contains the most 
> recent mainline-bound DTS data.  That should be enough to verify that the 
> basic boot works.  If you want to keep up with the ongoing development of 
> that data, the best bet is to subscribe to the linux-riscv mailing list.
> 
> 
> - Paul

I consider ‘basic boot’ to include a bootloader that can load BBL/SBI and
an payload (S-mode uboot, or a kernel/ramdisk/dtb/etc) via the network.

So this would be the time to agree on what the gemgxl/ethernet entries 
should look like, and all of this can get unblocked. What I have now that
I know works (with the legacy u-boot) is this:

                L51: cadence-gemgxl-mgmt@100a0000 {
                        compatible = "sifive,cadencegemgxlmgmt0";
                        reg = <0x0 0x100a0000 0x0 0x1000>;
                        reg-names = "control";
                        #clock-cells = <0>;
                };
                L52: ethernet@10090000 {
                        compatible = "cdns,macb";
                        interrupt-parent = <&L4>;
                        interrupts = <53>;
                        reg = <0x0 0x10090000 0x0 0x2000>;
                        reg-names = "control";

                        local-mac-address = [00 00 00 00 00 00];
                        phy-mode = "gmii";
                        clock-names = "pclk", "hclk", "tx_clk";
                        clocks = <&prci 1>, <&prci 1>, <&L51>;
                        #address-cells = <1>;
                        #size-cells = <0>;
                        phy1: ethernet-phy@0 {
                                reg = <0>;
                                reset-gpios = <&L31 12 1>;
                        };
                };
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: 5.2-rc1 boot on Unleashed
  2019-05-25 18:40               ` Troy Benjegerdes
@ 2019-05-27 12:21                 ` Andreas Schwab
  2019-05-27 16:51                   ` Troy Benjegerdes
  0 siblings, 1 reply; 42+ messages in thread
From: Andreas Schwab @ 2019-05-27 12:21 UTC (permalink / raw)
  To: Troy Benjegerdes
  Cc: Palmer Dabbelt, Björn Töpel, Anup Patel, Atish Patra,
	Yash Shah, Paul Walmsley, linux-riscv

On Mai 25 2019, Troy Benjegerdes <troy.benjegerdes@sifive.com> wrote:

> So this would be the time to agree on what the gemgxl/ethernet entries 
> should look like, and all of this can get unblocked. What I have now that
> I know works (with the legacy u-boot) is this:
>
>                 L51: cadence-gemgxl-mgmt@100a0000 {
>                         compatible = "sifive,cadencegemgxlmgmt0";
>                         reg = <0x0 0x100a0000 0x0 0x1000>;
>                         reg-names = "control";
>                         #clock-cells = <0>;
>                 };
>                 L52: ethernet@10090000 {
>                         compatible = "cdns,macb";
>                         interrupt-parent = <&L4>;
>                         interrupts = <53>;
>                         reg = <0x0 0x10090000 0x0 0x2000>;
>                         reg-names = "control";
>
>                         local-mac-address = [00 00 00 00 00 00];
>                         phy-mode = "gmii";
>                         clock-names = "pclk", "hclk", "tx_clk";
>                         clocks = <&prci 1>, <&prci 1>, <&L51>;

That can't be right, <&prci 1> is CLK_DDRPLL.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: 5.2-rc1 boot on Unleashed
  2019-05-27 12:21                 ` Andreas Schwab
@ 2019-05-27 16:51                   ` Troy Benjegerdes
  0 siblings, 0 replies; 42+ messages in thread
From: Troy Benjegerdes @ 2019-05-27 16:51 UTC (permalink / raw)
  To: Andreas Schwab
  Cc: Palmer Dabbelt, Björn Töpel, Anup Patel, Atish Patra,
	Yash Shah, Paul Walmsley, linux-riscv



> On May 27, 2019, at 7:21 AM, Andreas Schwab <schwab@suse.de> wrote:
> 
> On Mai 25 2019, Troy Benjegerdes <troy.benjegerdes@sifive.com> wrote:
> 
>> So this would be the time to agree on what the gemgxl/ethernet entries 
>> should look like, and all of this can get unblocked. What I have now that
>> I know works (with the legacy u-boot) is this:
>> 
>>                L51: cadence-gemgxl-mgmt@100a0000 {
>>                        compatible = "sifive,cadencegemgxlmgmt0";
>>                        reg = <0x0 0x100a0000 0x0 0x1000>;
>>                        reg-names = "control";
>>                        #clock-cells = <0>;
>>                };
>>                L52: ethernet@10090000 {
>>                        compatible = "cdns,macb";
>>                        interrupt-parent = <&L4>;
>>                        interrupts = <53>;
>>                        reg = <0x0 0x10090000 0x0 0x2000>;
>>                        reg-names = "control";
>> 
>>                        local-mac-address = [00 00 00 00 00 00];
>>                        phy-mode = "gmii";
>>                        clock-names = "pclk", "hclk", "tx_clk";
>>                        clocks = <&prci 1>, <&prci 1>, <&L51>;
> 
> That can't be right, <&prci 1> is CLK_DDRPLL.
> 
> Andreas.
> 

Okay that is definitely wrong then (for the new PRCI code)

I have a WIP commit of the new DTS format(s) in the legacy U-boot tree,
in which everything appears to work, and should at least be sufficient
for temporary use to ease development of other components (SBI, S-mode
Uboot, kernel), etc.

The patch for the DTS changes is at
https://github.com/tmagik/HiFive_U-Boot/commit/32b00e74e908dc72e85f2f6631c332ad3da619a0

I’ve tried both backporting the PRCI driver to linux 4.19, as well as Paul’s 5.1 test
kernel, however neither of them successfully boot in the flow I am using.


> -- 
> Andreas Schwab, SUSE Labs, schwab@suse.de
> GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
> "And now for something completely different."


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 42+ messages in thread

* RE: 5.2-rc1 boot on Unleashed
  2019-05-25 14:16           ` Troy Benjegerdes
@ 2019-05-29  5:00             ` Anup Patel
  2019-05-29  8:31               ` Andreas Schwab
  0 siblings, 1 reply; 42+ messages in thread
From: Anup Patel @ 2019-05-29  5:00 UTC (permalink / raw)
  To: Troy Benjegerdes, Anup Patel
  Cc: Björn Töpel, Palmer Dabbelt, Atish Patra, Lukas Auer,
	Paul Walmsley, linux-riscv, Bin Meng



> -----Original Message-----
> From: linux-riscv <linux-riscv-bounces@lists.infradead.org> On Behalf Of
> Troy Benjegerdes
> Sent: Saturday, May 25, 2019 7:46 PM
> To: Anup Patel <anup@brainfault.org>
> Cc: Palmer Dabbelt <palmer@sifive.com>; Björn Töpel
> <bjorn.topel@gmail.com>; Anup Patel <Anup.Patel@wdc.com>; Atish Patra
> <Atish.Patra@wdc.com>; Lukas Auer <lukas.auer@aisec.fraunhofer.de>;
> Paul Walmsley <paul.walmsley@sifive.com>; linux-riscv@lists.infradead.org;
> Bin Meng <bmeng.cn@gmail.com>
> Subject: Re: 5.2-rc1 boot on Unleashed
> 
> 
> 
> > On May 25, 2019, at 3:06 AM, Anup Patel <anup@brainfault.org> wrote:
> >
> > Hi Troy,
> >
> > On Thu, May 23, 2019 at 3:45 AM Troy Benjegerdes
> > <troy.benjegerdes@sifive.com> wrote:
> >>
> >>
> >>> On May 22, 2019, at 3:43 PM, Paul Walmsley
> <paul.walmsley@sifive.com> wrote:
> >>>
> >>> + Anup, Troy
> >>>
> >>> On Wed, 22 May 2019, Atish Patra wrote:
> >>>
> >>>> On 5/22/19 9:42 AM, Paul Walmsley wrote:
> >>>>> Am checking on this now and hope to have some conclusion on it this
> week.
> >>>>
> >>>> Thanks. Any chance you can take a look at the U-Boot clock driver
> >>>> to patch it as per the DT changes ?
> >>>
> >>> I probably won't have the chance to get to it for a while.  Looks
> >>> like Anup was the one who posted the clock driver to U-Boot - can he
> >>> take a look at it?
> >>>
> >>> We've also asked Troy to look at upstream U-boot related issues, but
> >>> I'm unsure when patches will start flowing upstream.
> >>>
> >>>
> >>> - Paul
> >>
> >> Once I figure out why I’m getting TX timeouts on the macb driver and
> have something working I can start upstreaming the u-boot patches.
> >>
> >> For now, the work-in-progress is at
> >> https://github.com/sifive/u-boot/tree/sandbox
> >
> > Based on your commits in above GitRepo, it seems you are trying entire
> > U-Boot in M-mode.
> >
> > Current boot-flow of S-mode U-Boot is:
> > ZSBL (M-mode) -> FSBL (M-mode) -> OpenSBI/BBL (M-mode) -> U-Boot
> > (S-mode)
> >
> > The U-Boot SPL can perfectly replace SiFive FSBL to have following
> > boot-flow:
> > ZSBL (M-mode) -> U-Boot SPL (M-mode) -> OpenSBI/BBL (M-mode) -> U-
> Boot
> > (S-mode)
> >
> > Can you explain advantages of using full U-Boot M-mode to replace FSBL
> > as compared to U-Boot SPL M-mode replacing FSBL ?
> >
> > Regards,
> > Anup
> 
> The current flow in Freedom-u-sdk (with
> https://github.com/sifive/HiFive_U-Boot) is this:
> ZSBL (M-mode) -> U-Boot (M-mode) -> BBL -> Linux kernel
> 
> The major driver for full U-Boot M-mode is automated regression testing and
> being able to load the SBI interface (BBL or OpenSBI) and linux kernel via
> TFTP.

This is a very specific use-case. The RISC-V boot flow should be compliant with
major architectures (ARM/ARM64 and x86) so that it's very easy (and boring)
for folks (familiar with these major architectures) to try-out RISC-V.

To achieve this, we need to ensure that users are able to boot kernel Image
and Image.gz without embedding it in OpenSBI/BBL. In fact, we also need to
ensure that users can update SBI runtime (OpenSBI/BBL) and bootloader
(i.e. U-Boot) separately.

If we try to address above requirements then we end-up having U-Boot S-mode
(or any S-mode bootloader) as last stage before kernel and SBI runtime will be
before U-Boot S-mode as separate binary.

Due to above, we have come-up with FW_JUMP and FW_DYNAMIC firmwares
in OpenSBI. These firmwares don't embed Linux kernel or Bootloader binary
and can be loaded separately.

> 
> I do agree U-Boot SPL is a very good idea, I have been working on replicating
> the functionality of the old HiFive U-boot first and then once that works I
> think it will be a lot easier to work out the SPL option.

Yes, U-Boot SPI (M-mode) will be the right way to go and it will fit in lot
of use-cases.

Regards,
Anup
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: 5.2-rc1 boot on Unleashed
  2019-05-29  5:00             ` Anup Patel
@ 2019-05-29  8:31               ` Andreas Schwab
  2019-05-29 17:38                 ` Troy Benjegerdes
  0 siblings, 1 reply; 42+ messages in thread
From: Andreas Schwab @ 2019-05-29  8:31 UTC (permalink / raw)
  To: Anup Patel
  Cc: Anup Patel, Palmer Dabbelt, Atish Patra, Lukas Auer,
	Paul Walmsley, Björn Töpel, Troy Benjegerdes,
	linux-riscv, Bin Meng

On Mai 29 2019, Anup Patel <Anup.Patel@wdc.com> wrote:

> To achieve this, we need to ensure that users are able to boot kernel Image
> and Image.gz without embedding it in OpenSBI/BBL.

Especially you need to ensure that you can load a separate initrd,
without the need to encapsulate it further as it is currently required
with u-Boot loading.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: 5.2-rc1 boot on Unleashed
  2019-05-29  8:31               ` Andreas Schwab
@ 2019-05-29 17:38                 ` Troy Benjegerdes
  2019-05-29 18:59                   ` Karsten Merker
  0 siblings, 1 reply; 42+ messages in thread
From: Troy Benjegerdes @ 2019-05-29 17:38 UTC (permalink / raw)
  To: Andreas Schwab
  Cc: Palmer Dabbelt, Anup Patel, Anup Patel, Atish Patra, Lukas Auer,
	Paul Walmsley, Björn Töpel, linux-riscv, Bin Meng



> On May 29, 2019, at 3:31 AM, Andreas Schwab <schwab@suse.de> wrote:
> 
> On Mai 29 2019, Anup Patel <Anup.Patel@wdc.com> wrote:
> 
>> To achieve this, we need to ensure that users are able to boot kernel Image
>> and Image.gz without embedding it in OpenSBI/BBL.
> 
> Especially you need to ensure that you can load a separate initrd,
> without the need to encapsulate it further as it is currently required
> with u-Boot loading.
> 
> Andreas.
> 

This has been possible for at least 6 months now with the legacy HiFive-U-boot
that is integrated in https://github.com/sifive/freedom-u-sdk

Currently the build scripts generate a single hifiveu.fit image that U-boot
loads, however it is relatively straightforward to change the uEnv.txt file
to load BBL, the kernel, device tree, and initrd separately.

If some examples (and flashable binary images) demonstrating this would
be useful, let me know and I will make some updates.

What I could use some help on is how we should be using 
config_distro_bootcmd.h in u-boot to follow what other architectures
have done, or if that approach is needlessly complicating things that
we could do in a much cleaner way with a clean slate.


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: 5.2-rc1 boot on Unleashed
  2019-05-29 17:38                 ` Troy Benjegerdes
@ 2019-05-29 18:59                   ` Karsten Merker
  2019-05-30 17:00                     ` Palmer Dabbelt
  2019-06-03 10:49                     ` Andreas Schwab
  0 siblings, 2 replies; 42+ messages in thread
From: Karsten Merker @ 2019-05-29 18:59 UTC (permalink / raw)
  To: Troy Benjegerdes
  Cc: Palmer Dabbelt, Andreas Schwab, Anup Patel, Atish Patra,
	Lukas Auer, Paul Walmsley, Anup Patel, linux-riscv, Bin Meng,
	Björn Töpel

On Wed, May 29, 2019 at 12:38:42PM -0500, Troy Benjegerdes wrote:
> > On May 29, 2019, at 3:31 AM, Andreas Schwab <schwab@suse.de> wrote:
> > 
> > On Mai 29 2019, Anup Patel <Anup.Patel@wdc.com> wrote:
> > 
> >> To achieve this, we need to ensure that users are able to boot kernel Image
> >> and Image.gz without embedding it in OpenSBI/BBL.
> > 
> > Especially you need to ensure that you can load a separate initrd,
> > without the need to encapsulate it further as it is currently required
> > with u-Boot loading.
> > 
> > Andreas.
> > 
> 
> This has been possible for at least 6 months now with the legacy HiFive-U-boot
> that is integrated in https://github.com/sifive/freedom-u-sdk
> 
> Currently the build scripts generate a single hifiveu.fit image that U-boot
> loads, however it is relatively straightforward to change the uEnv.txt file
> to load BBL, the kernel, device tree, and initrd separately.
> 
> If some examples (and flashable binary images) demonstrating this would
> be useful, let me know and I will make some updates.
> 
> What I could use some help on is how we should be using 
> config_distro_bootcmd.h in u-boot to follow what other architectures
> have done, or if that approach is needlessly complicating things that
> we could do in a much cleaner way with a clean slate.

Hello,

speaking with my Linux distribution maintainer hat on, you should
definitely use config_distro_bootcmd.h as that is the interface
that all binary Linux distributions expect from U-Boot nowadays. 
Please don't try to invent your own, incompatible boot
environment; we have had that situation on arm-based systems for
years before config_distro_bootcmd.h was introduced in 2014 and
it was horrible.  Really nobody wants to have that again on
modern systems.

Mainline U-Boot already uses the distro bootcmd environment for
the qemu "virt" machine and it works well.

Regards,
Karsten
-- 
Ich widerspreche hiermit ausdrücklich der Nutzung sowie der
Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung
sowie der Markt- oder Meinungsforschung.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: 5.2-rc1 boot on Unleashed
  2019-05-29 18:59                   ` Karsten Merker
@ 2019-05-30 17:00                     ` Palmer Dabbelt
  2019-06-03 10:49                     ` Andreas Schwab
  1 sibling, 0 replies; 42+ messages in thread
From: Palmer Dabbelt @ 2019-05-30 17:00 UTC (permalink / raw)
  To: merker
  Cc: schwab, Anup Patel, Atish Patra, lukas.auer, Paul Walmsley, anup,
	Troy Benjegerdes, linux-riscv, bmeng.cn,
	Björn Töpel

On Wed, 29 May 2019 11:59:51 PDT (-0700), merker@debian.org wrote:
> On Wed, May 29, 2019 at 12:38:42PM -0500, Troy Benjegerdes wrote:
>> > On May 29, 2019, at 3:31 AM, Andreas Schwab <schwab@suse.de> wrote:
>> >
>> > On Mai 29 2019, Anup Patel <Anup.Patel@wdc.com> wrote:
>> >
>> >> To achieve this, we need to ensure that users are able to boot kernel Image
>> >> and Image.gz without embedding it in OpenSBI/BBL.
>> >
>> > Especially you need to ensure that you can load a separate initrd,
>> > without the need to encapsulate it further as it is currently required
>> > with u-Boot loading.
>> >
>> > Andreas.
>> >
>>
>> This has been possible for at least 6 months now with the legacy HiFive-U-boot
>> that is integrated in https://github.com/sifive/freedom-u-sdk
>>
>> Currently the build scripts generate a single hifiveu.fit image that U-boot
>> loads, however it is relatively straightforward to change the uEnv.txt file
>> to load BBL, the kernel, device tree, and initrd separately.
>>
>> If some examples (and flashable binary images) demonstrating this would
>> be useful, let me know and I will make some updates.

I don't care about the out of tree stuff.  The core of this issue is that
everyone's got a bunch of out-of-tree patches floating around, which means
everyone's running into different bugs.  Linux has been the central headache
for more than a year, but now that's starting to get into acceptable shape the
headache is the boot flow.

>> What I could use some help on is how we should be using
>> config_distro_bootcmd.h in u-boot to follow what other architectures
>> have done, or if that approach is needlessly complicating things that
>> we could do in a much cleaner way with a clean slate.
>
> Hello,
>
> speaking with my Linux distribution maintainer hat on, you should
> definitely use config_distro_bootcmd.h as that is the interface
> that all binary Linux distributions expect from U-Boot nowadays.
> Please don't try to invent your own, incompatible boot
> environment; we have had that situation on arm-based systems for
> years before config_distro_bootcmd.h was introduced in 2014 and
> it was horrible.  Really nobody wants to have that again on
> modern systems.

I agree.  The general goal with the RISC-V software ecosystem is that we should
be as boring as possible.  Specifically, if something works fine for all the
other platforms then we should just copy it.  While I'm not well versed in the
boot flow, from my understanding of this the arm64 guys have something
reasonable and we should just follow in their footsteps.

That's certainly what's going on in the kernel with that header patch.  There's
a lot of debate there, but the debate is really "does this actually match what
arm64 does?", not "should we copy what am64 does?".

> Mainline U-Boot already uses the distro bootcmd environment for
> the qemu "virt" machine and it works well.

OK, so it sounds like the RISC-V stuff works and all we need to do is get
SiFive's platform working in upstream u-boot.  On the distro side you should
just count on that happening, we'll go fix it.  This is the second time this
week I've had trouble with this whole bootloader mess, so I guess that means
it's time to go figure it out :)

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: 5.2-rc1 boot on Unleashed
  2019-05-29 18:59                   ` Karsten Merker
  2019-05-30 17:00                     ` Palmer Dabbelt
@ 2019-06-03 10:49                     ` Andreas Schwab
  2019-06-03 14:44                       ` Distro bootcmd: " Troy Benjegerdes
  1 sibling, 1 reply; 42+ messages in thread
From: Andreas Schwab @ 2019-06-03 10:49 UTC (permalink / raw)
  To: Karsten Merker
  Cc: Palmer Dabbelt, Anup Patel, Anup Patel, Atish Patra, Lukas Auer,
	Paul Walmsley, Troy Benjegerdes, linux-riscv, Bin Meng,
	Björn Töpel

On Mai 29 2019, Karsten Merker <merker@debian.org> wrote:

> Mainline U-Boot already uses the distro bootcmd environment for
> the qemu "virt" machine and it works well.

The distro_bootcmd doesn't work for the sifive platform yet because it
doesn't set the correct MAC address for booting.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Distro bootcmd: Re: 5.2-rc1 boot on Unleashed
  2019-06-03 10:49                     ` Andreas Schwab
@ 2019-06-03 14:44                       ` " Troy Benjegerdes
  2019-06-03 17:02                         ` [U-Boot] " Tom Rini
  0 siblings, 1 reply; 42+ messages in thread
From: Troy Benjegerdes @ 2019-06-03 14:44 UTC (permalink / raw)
  To: Andreas Schwab, Karsten Merker
  Cc: Palmer Dabbelt, Dany Nativel, u-boot, Anup Patel, Anup Patel,
	Atish Patra, Lukas Auer, Paul Walmsley, linux-riscv, Bin Meng,
	Björn Töpel



> On Jun 3, 2019, at 5:49 AM, Andreas Schwab <schwab@suse.de> wrote:
> 
> On Mai 29 2019, Karsten Merker <merker@debian.org> wrote:
> 
>> Mainline U-Boot already uses the distro bootcmd environment for
>> the qemu "virt" machine and it works well.
> 
> The distro_bootcmd doesn't work for the sifive platform yet because it
> doesn't set the correct MAC address for booting.
> 
> Andreas.
> 

Before we go an use distro_bootcmd and drag in a bunch of legacy stuff 
we really should not be using, can we make some kind of effort to decide
what the design goals and boot flow should look like instead using the 
default legacy behavior of a bunch of hard to read and maintain CPP
macros?

The first thing I notice is that the default dhcp target is ‘boot.scr.uimg’.

What good does it do linux distros on RiscV to keep using the old boot
script format, rather than just load a text file and use ‘env import’? Is there
some benefit to this? Do we gain something from the .scr format, like
maybe cryptographic signature support?

How do we want to support secure boot into Debian, Fedora, and Suse,
and does distro_bootcmd have a way to do this, or can we come up with
some improvement that doesn’t depend on trying to do all the work in
CPP macros and U-boot runtime scripts?


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [U-Boot] Distro bootcmd: Re: 5.2-rc1 boot on Unleashed
  2019-06-03 14:44                       ` Distro bootcmd: " Troy Benjegerdes
@ 2019-06-03 17:02                         ` " Tom Rini
  2019-06-03 19:17                           ` Palmer Dabbelt
  2019-06-03 19:47                           ` Troy Benjegerdes
  0 siblings, 2 replies; 42+ messages in thread
From: Tom Rini @ 2019-06-03 17:02 UTC (permalink / raw)
  To: Troy Benjegerdes
  Cc: Dany Nativel, Andreas Schwab, Palmer Dabbelt, u-boot,
	Björn Töpel, Karsten Merker, linux-riscv

[-- Attachment #1.1: Type: text/plain, Size: 2563 bytes --]

On Mon, Jun 03, 2019 at 09:44:28AM -0500, Troy Benjegerdes wrote:
> 
> 
> > On Jun 3, 2019, at 5:49 AM, Andreas Schwab <schwab@suse.de> wrote:
> > 
> > On Mai 29 2019, Karsten Merker <merker@debian.org> wrote:
> > 
> >> Mainline U-Boot already uses the distro bootcmd environment for
> >> the qemu "virt" machine and it works well.
> > 
> > The distro_bootcmd doesn't work for the sifive platform yet because it
> > doesn't set the correct MAC address for booting.
> > 
> > Andreas.
> > 
> 
> Before we go an use distro_bootcmd and drag in a bunch of legacy stuff 
> we really should not be using, can we make some kind of effort to decide
> what the design goals and boot flow should look like instead using the 
> default legacy behavior of a bunch of hard to read and maintain CPP
> macros?

I feel like you're calling "what everyone agreed on and uses today"
legacy just because it already exists.  It is a bit complex because
devices are so complex, rather than it having to support one-off
situations or similar things people usually call "legacy".

> The first thing I notice is that the default dhcp target is ‘boot.scr.uimg’.
> 
> What good does it do linux distros on RiscV to keep using the old boot
> script format, rather than just load a text file and use ‘env import’? Is there
> some benefit to this? Do we gain something from the .scr format, like
> maybe cryptographic signature support?

Writing things out in script format ends up being more natural (and
easier to understand) than writing things out in environment format.
This is why while I wish the "uEnv.txt" hook had become more popular and
widely used, at this point I also understand why it wasn't.  Doing
a=foo
b=bar
c=baz
magic_name=do this;do that

Was not easier nor more understandable than:
setenv a foo
setenv b bar
setenv c baz
do this; do that

> How do we want to support secure boot into Debian, Fedora, and Suse,
> and does distro_bootcmd have a way to do this, or can we come up with
> some improvement that doesn’t depend on trying to do all the work in
> CPP macros and U-boot runtime scripts?

I think the general answer about "secure boot" is that distros want
"UEFI secure boot".  And I want to make sure that's done in such a way
that things like user-owned secure boot aren't any more difficult than
vendor secured boot.  It seems like making use of existing secure boot
mechanisms has set aside as, well, I don't want to throw snark around
myself, so I'll refrain from speculating.

-- 
Tom

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 161 bytes --]

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [U-Boot] Distro bootcmd: Re: 5.2-rc1 boot on Unleashed
  2019-06-03 17:02                         ` [U-Boot] " Tom Rini
@ 2019-06-03 19:17                           ` Palmer Dabbelt
  2019-06-03 19:32                             ` Tom Rini
  2019-06-03 19:47                           ` Troy Benjegerdes
  1 sibling, 1 reply; 42+ messages in thread
From: Palmer Dabbelt @ 2019-06-03 19:17 UTC (permalink / raw)
  To: trini
  Cc: Dany Nativel, schwab, U-Boot, Björn Töpel,
	Troy Benjegerdes, linux-riscv, merker

On Mon, 03 Jun 2019 10:02:57 PDT (-0700), trini@konsulko.com wrote:
> On Mon, Jun 03, 2019 at 09:44:28AM -0500, Troy Benjegerdes wrote:
>> 
>> 
>> > On Jun 3, 2019, at 5:49 AM, Andreas Schwab <schwab@suse.de> wrote:
>> > 
>> > On Mai 29 2019, Karsten Merker <merker@debian.org> wrote:
>> > 
>> >> Mainline U-Boot already uses the distro bootcmd environment for
>> >> the qemu "virt" machine and it works well.
>> > 
>> > The distro_bootcmd doesn't work for the sifive platform yet because it
>> > doesn't set the correct MAC address for booting.
>> > 
>> > Andreas.
>> > 
>> 
>> Before we go an use distro_bootcmd and drag in a bunch of legacy stuff 
>> we really should not be using, can we make some kind of effort to decide
>> what the design goals and boot flow should look like instead using the 
>> default legacy behavior of a bunch of hard to read and maintain CPP
>> macros?
>
> I feel like you're calling "what everyone agreed on and uses today"
> legacy just because it already exists.  It is a bit complex because
> devices are so complex, rather than it having to support one-off
> situations or similar things people usually call "legacy".

The goal in RISC-V land is to avoid inventing our own stuff, particularly when
there's an agreed upon way of doing things.  As far as I can tell the users
(ie, distros) all want this distro_bootcmd stuff because it's what already
works in ARM land.  While I'm not really a bootloader guy, the general
arguments in favor of distro_bootcmd appaer to be "we tried it some other ways
and that was a mess, but this way works".  That is a really strong argument to
me.

>> The first thing I notice is that the default dhcp target is ‘boot.scr.uimg’.
>> 
>> What good does it do linux distros on RiscV to keep using the old boot
>> script format, rather than just load a text file and use ‘env import’? Is there
>> some benefit to this? Do we gain something from the .scr format, like
>> maybe cryptographic signature support?
>
> Writing things out in script format ends up being more natural (and
> easier to understand) than writing things out in environment format.
> This is why while I wish the "uEnv.txt" hook had become more popular and
> widely used, at this point I also understand why it wasn't.  Doing
> a=foo
> b=bar
> c=baz
> magic_name=do this;do that
>
> Was not easier nor more understandable than:
> setenv a foo
> setenv b bar
> setenv c baz
> do this; do that
>
>> How do we want to support secure boot into Debian, Fedora, and Suse,
>> and does distro_bootcmd have a way to do this, or can we come up with
>> some improvement that doesn’t depend on trying to do all the work in
>> CPP macros and U-boot runtime scripts?
>
> I think the general answer about "secure boot" is that distros want
> "UEFI secure boot".  And I want to make sure that's done in such a way
> that things like user-owned secure boot aren't any more difficult than
> vendor secured boot.  It seems like making use of existing secure boot
> mechanisms has set aside as, well, I don't want to throw snark around
> myself, so I'll refrain from speculating.
>
> -- 
> Tom

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [U-Boot] Distro bootcmd: Re: 5.2-rc1 boot on Unleashed
  2019-06-03 19:17                           ` Palmer Dabbelt
@ 2019-06-03 19:32                             ` Tom Rini
  0 siblings, 0 replies; 42+ messages in thread
From: Tom Rini @ 2019-06-03 19:32 UTC (permalink / raw)
  To: Palmer Dabbelt
  Cc: Dany Nativel, schwab, U-Boot, Björn Töpel,
	Troy Benjegerdes, linux-riscv, merker

[-- Attachment #1.1: Type: text/plain, Size: 2204 bytes --]

On Mon, Jun 03, 2019 at 12:17:43PM -0700, Palmer Dabbelt wrote:
> On Mon, 03 Jun 2019 10:02:57 PDT (-0700), trini@konsulko.com wrote:
> >On Mon, Jun 03, 2019 at 09:44:28AM -0500, Troy Benjegerdes wrote:
> >>
> >>
> >>> On Jun 3, 2019, at 5:49 AM, Andreas Schwab <schwab@suse.de> wrote:
> >>> > On Mai 29 2019, Karsten Merker <merker@debian.org> wrote:
> >>> >> Mainline U-Boot already uses the distro bootcmd environment for
> >>>> the qemu "virt" machine and it works well.
> >>> > The distro_bootcmd doesn't work for the sifive platform yet because
> >>it
> >>> doesn't set the correct MAC address for booting.
> >>> > Andreas.
> >>>
> >>
> >>Before we go an use distro_bootcmd and drag in a bunch of legacy stuff
> >>we really should not be using, can we make some kind of effort to decide
> >>what the design goals and boot flow should look like instead using the
> >>default legacy behavior of a bunch of hard to read and maintain CPP
> >>macros?
> >
> >I feel like you're calling "what everyone agreed on and uses today"
> >legacy just because it already exists.  It is a bit complex because
> >devices are so complex, rather than it having to support one-off
> >situations or similar things people usually call "legacy".
> 
> The goal in RISC-V land is to avoid inventing our own stuff, particularly when
> there's an agreed upon way of doing things.  As far as I can tell the users
> (ie, distros) all want this distro_bootcmd stuff because it's what already
> works in ARM land.  While I'm not really a bootloader guy, the general
> arguments in favor of distro_bootcmd appaer to be "we tried it some other ways
> and that was a mess, but this way works".  That is a really strong argument to
> me.

Right.  While I'm sure there's room for improvement, the distro_bootcmd
stuff was borne out of working with the distro folks to get what was
needed so they could Just Install on whatever SBC the user had.

And the EBBR spec (which in turn, roughly, is a subset of UEFI) intends
to make that more formal still.

As long as we can avoid <long list of problems I've personally had doing
things on x86_64> I think that's a good thing, overall.

-- 
Tom

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 161 bytes --]

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [U-Boot] Distro bootcmd: Re: 5.2-rc1 boot on Unleashed
  2019-06-03 17:02                         ` [U-Boot] " Tom Rini
  2019-06-03 19:17                           ` Palmer Dabbelt
@ 2019-06-03 19:47                           ` Troy Benjegerdes
  1 sibling, 0 replies; 42+ messages in thread
From: Troy Benjegerdes @ 2019-06-03 19:47 UTC (permalink / raw)
  To: Tom Rini
  Cc: Dany Nativel, Andreas Schwab, Palmer Dabbelt, u-boot,
	Björn Töpel, Karsten Merker, linux-riscv



> On Jun 3, 2019, at 12:02 PM, Tom Rini <trini@konsulko.com> wrote:
> 
> On Mon, Jun 03, 2019 at 09:44:28AM -0500, Troy Benjegerdes wrote:
>> 
>> 
>>> On Jun 3, 2019, at 5:49 AM, Andreas Schwab <schwab@suse.de> wrote:
>>> 
>>> On Mai 29 2019, Karsten Merker <merker@debian.org> wrote:
>>> 
>>>> Mainline U-Boot already uses the distro bootcmd environment for
>>>> the qemu "virt" machine and it works well.
>>> 
>>> The distro_bootcmd doesn't work for the sifive platform yet because it
>>> doesn't set the correct MAC address for booting.
>>> 
>>> Andreas.
>>> 
>> 
>> Before we go an use distro_bootcmd and drag in a bunch of legacy stuff 
>> we really should not be using, can we make some kind of effort to decide
>> what the design goals and boot flow should look like instead using the 
>> default legacy behavior of a bunch of hard to read and maintain CPP
>> macros?
> 
> I feel like you're calling "what everyone agreed on and uses today"
> legacy just because it already exists.  It is a bit complex because
> devices are so complex, rather than it having to support one-off
> situations or similar things people usually call "legacy”.

My biggest complaint is all the CPP macros, which are really hard to
maintain and read.

I should probably be more careful to quantify ‘legacy’ much more
specifically as “legacy proprietary ROM code”. Or maybe that’s not 
the right term at all

For the first time I know of, we have a (mostly) blank slate to write
the ROM boot code to help manage boot complexity. So I’d like to
make sure we can tease out all the reasons we have all this important
logic and knowledge tied up in a single header file, and at least
re-examine is there a better way to do this than abusing CPP.

> 
>> The first thing I notice is that the default dhcp target is ‘boot.scr.uimg’.
>> 
>> What good does it do linux distros on RiscV to keep using the old boot
>> script format, rather than just load a text file and use ‘env import’? Is there
>> some benefit to this? Do we gain something from the .scr format, like
>> maybe cryptographic signature support?
> 
> Writing things out in script format ends up being more natural (and
> easier to understand) than writing things out in environment format.
> This is why while I wish the "uEnv.txt" hook had become more popular and
> widely used, at this point I also understand why it wasn't.  Doing
> a=foo
> b=bar
> c=baz
> magic_name=do this;do that
> 
> Was not easier nor more understandable than:
> setenv a foo
> setenv b bar
> setenv c baz
> do this; do that

uEnv has the significant user experience advantage of being editable with
a plain old text editor, which is why I used it in freedom-u-sdk. If we can get
a ’script’ format that can be edited by a non-technical user on a windows or
mac box without requiring mkimage, then we have an improvement. Can
this be done with .scr currently?

> 
>> How do we want to support secure boot into Debian, Fedora, and Suse,
>> and does distro_bootcmd have a way to do this, or can we come up with
>> some improvement that doesn’t depend on trying to do all the work in
>> CPP macros and U-boot runtime scripts?
> 
> I think the general answer about "secure boot" is that distros want
> "UEFI secure boot".  And I want to make sure that's done in such a way
> that things like user-owned secure boot aren't any more difficult than
> vendor secured boot.  It seems like making use of existing secure boot
> mechanisms has set aside as, well, I don't want to throw snark around
> myself, so I'll refrain from speculating.
> 
> -- 
> Tom

The problematic issue with ‘user-owned secure boot’ is it’s never been a
major ‘business critical’ need, so it’s always ended up lower on the priority
list from anyone who’s looking at what their clients are paying for.

Now on that note, I think maybe the best way to approach this is to start
with a clear community consensus that we MUST support a user experience
where an end-user with an open RiscV device MUST be able to edit the
boot parameters (boot script? uEnv.txt?), and then be able to resign the
script with their key(s), so the system can boot and maintain a secured 
state when it gets to userspace where we are running distro-signed
binaries.

I honestly don’t know of anyone that’s really looked at this in a commercial
setting other than maybe purism, and they are a pretty niche vendor, and
stuck with a lot of x86 legacy to deal with.
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 42+ messages in thread

end of thread, back to index

Thread overview: 42+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-05-20 23:31 5.2-rc1 boot on Unleashed Atish Patra
2019-05-21  9:40 ` Andreas Schwab
2019-05-21 18:14   ` Atish Patra
2019-05-22  7:31     ` Andreas Schwab
2019-05-22  8:40     ` Andreas Schwab
2019-05-22  9:58     ` Andreas Schwab
2019-05-22 21:13       ` Paul Walmsley
2019-05-21 17:47 ` Kevin Hilman
2019-05-21 18:18   ` Atish Patra
2019-05-23  9:42     ` Andreas Schwab
2019-05-22  4:42 ` Sagar Kadam
2019-05-22  9:51   ` Atish Patra
2019-05-22 16:42 ` Paul Walmsley
2019-05-22 17:38   ` Atish Patra
2019-05-22 20:43     ` Paul Walmsley
2019-05-22 22:14       ` Troy Benjegerdes
2019-05-25  8:06         ` Anup Patel
2019-05-25 14:16           ` Troy Benjegerdes
2019-05-29  5:00             ` Anup Patel
2019-05-29  8:31               ` Andreas Schwab
2019-05-29 17:38                 ` Troy Benjegerdes
2019-05-29 18:59                   ` Karsten Merker
2019-05-30 17:00                     ` Palmer Dabbelt
2019-06-03 10:49                     ` Andreas Schwab
2019-06-03 14:44                       ` Distro bootcmd: " Troy Benjegerdes
2019-06-03 17:02                         ` [U-Boot] " Tom Rini
2019-06-03 19:17                           ` Palmer Dabbelt
2019-06-03 19:32                             ` Tom Rini
2019-06-03 19:47                           ` Troy Benjegerdes
2019-05-24  0:23       ` Troy Benjegerdes
2019-05-24  3:59         ` Atish Patra
2019-05-24 14:46           ` Troy Benjegerdes
2019-05-24 15:35             ` Auer, Lukas
2019-05-24 16:01               ` Troy Benjegerdes
2019-05-24 17:40                 ` Atish Patra
     [not found]                   ` <CAF5mof3_PSwpsSMnjMALpfvmOPdeAgDLa2p6jp4y+Hmas83mbw@mail.gmail.com>
2019-05-24 21:34                     ` Auer, Lukas
2019-05-25  3:49                       ` Anup Patel
2019-05-25 16:23                         ` Troy Benjegerdes
2019-05-25 18:09             ` Paul Walmsley
2019-05-25 18:40               ` Troy Benjegerdes
2019-05-27 12:21                 ` Andreas Schwab
2019-05-27 16:51                   ` Troy Benjegerdes

Linux-RISC-V Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-riscv/0 linux-riscv/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-riscv linux-riscv/ https://lore.kernel.org/linux-riscv \
		linux-riscv@lists.infradead.org infradead-linux-riscv@archiver.kernel.org
	public-inbox-index linux-riscv


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.infradead.lists.linux-riscv


AGPL code for this site: git clone https://public-inbox.org/ public-inbox