* 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 related [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-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 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-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-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-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 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-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-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-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-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 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-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 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
* 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
[parent not found: <CAF5mof3_PSwpsSMnjMALpfvmOPdeAgDLa2p6jp4y+Hmas83mbw@mail.gmail.com>]
* 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-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
end of thread, other threads:[~2019-06-03 19:48 UTC | newest] 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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).