Message ID | 5c1ffb76-b18a-dbae-d3ad-f3d2cd41ee44@wdc.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | 5.2-rc1 boot on Unleashed | expand |
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.
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
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
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 >
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
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.
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.
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 >
What does that mean? [ 9.538450] of_fixed_factor_clk: probe of soc:tlclk failed with error -17 Andreas.
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
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 ?
+ 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
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
> 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
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.
> 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?
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.
> 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
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
> 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.
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. >
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. > > > > > > >
> -----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. > > > > > > > > > >
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
> 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.
> 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
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
> 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>; }; };
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.
> 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."
> -----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
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.
> 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.
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
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 :)
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.
> 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?
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.
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
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.
> 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.
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;
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> ----------------------------------------------------------------- Can somebody please look into this so that we can avoid this ugly hack ?