Message ID | 20190211054030.21393-1-anup.patel@wdc.com |
---|---|
Headers | show |
Series | SiFive FU540 Support | expand |
On Feb 11 2019, Anup Patel <Anup.Patel@wdc.com> wrote: > This patchset adds SiFive Freedom Unleashed (FU540) support > to RISC-V U-Boot. > > The patches are based upon latest U-Boot source tree > (git://git.denx.de/u-boot.git) at commit id > dbe70c7d4e3d5c705a98d82952e05a591efd0683 > > All drivers namely: SiFive PRCI, SiFive Serial, and Cadance > MACB Ethernet work fine on actual SiFive Unleashed board and > QEMU sifive_u machine. Looks like the MACB driver cannot find the correct MAC address. That makes it rather awkward for network boot. Warning: ethernet@10090000 (eth0) using random MAC address - 0e:14:15:06:ae:e4 Andreas.
On Mon, Feb 11, 2019 at 9:07 PM Andreas Schwab <schwab@suse.de> wrote: > > On Feb 11 2019, Anup Patel <Anup.Patel@wdc.com> wrote: > > > This patchset adds SiFive Freedom Unleashed (FU540) support > > to RISC-V U-Boot. > > > > The patches are based upon latest U-Boot source tree > > (git://git.denx.de/u-boot.git) at commit id > > dbe70c7d4e3d5c705a98d82952e05a591efd0683 > > > > All drivers namely: SiFive PRCI, SiFive Serial, and Cadance > > MACB Ethernet work fine on actual SiFive Unleashed board and > > QEMU sifive_u machine. > > Looks like the MACB driver cannot find the correct MAC address. That > makes it rather awkward for network boot. > > Warning: ethernet@10090000 (eth0) using random MAC address - 0e:14:15:06:ae:e4 This is because we don't have place to put U-Boot environment variables as of now on Unleashed board. This will be solved once we have SPI driver and SPI_MMC driver for Unleased board. In future, we will be saving "ethaddr" environment variable on SPI_MMC so U-Boot will pick MAC address at boot-time from SPI_MMC. Once this is achieved, the above warning will go away. Regards, Anup
> Am 12.02.2019 um 03:57 schrieb Anup Patel <anup@brainfault.org>: > >> On Mon, Feb 11, 2019 at 9:07 PM Andreas Schwab <schwab@suse.de> wrote: >> >>> On Feb 11 2019, Anup Patel <Anup.Patel@wdc.com> wrote: >>> >>> This patchset adds SiFive Freedom Unleashed (FU540) support >>> to RISC-V U-Boot. >>> >>> The patches are based upon latest U-Boot source tree >>> (git://git.denx.de/u-boot.git) at commit id >>> dbe70c7d4e3d5c705a98d82952e05a591efd0683 >>> >>> All drivers namely: SiFive PRCI, SiFive Serial, and Cadance >>> MACB Ethernet work fine on actual SiFive Unleashed board and >>> QEMU sifive_u machine. >> >> Looks like the MACB driver cannot find the correct MAC address. That >> makes it rather awkward for network boot. >> >> Warning: ethernet@10090000 (eth0) using random MAC address - 0e:14:15:06:ae:e4 > > This is because we don't have place to put U-Boot environment > variables as of now on Unleashed board. This will be solved once > we have SPI driver and SPI_MMC driver for Unleased board. > > In future, we will be saving "ethaddr" environment variable on > SPI_MMC so U-Boot will pick MAC address at boot-time from > SPI_MMC. Once this is achieved, the above warning will go away. How is the MAC determined in Linux? Alex > > Regards, > Anup
On Tue, Feb 12, 2019 at 11:52 AM Alexander Graf <agraf@suse.de> wrote: > > > > > Am 12.02.2019 um 03:57 schrieb Anup Patel <anup@brainfault.org>: > > > >> On Mon, Feb 11, 2019 at 9:07 PM Andreas Schwab <schwab@suse.de> wrote: > >> > >>> On Feb 11 2019, Anup Patel <Anup.Patel@wdc.com> wrote: > >>> > >>> This patchset adds SiFive Freedom Unleashed (FU540) support > >>> to RISC-V U-Boot. > >>> > >>> The patches are based upon latest U-Boot source tree > >>> (git://git.denx.de/u-boot.git) at commit id > >>> dbe70c7d4e3d5c705a98d82952e05a591efd0683 > >>> > >>> All drivers namely: SiFive PRCI, SiFive Serial, and Cadance > >>> MACB Ethernet work fine on actual SiFive Unleashed board and > >>> QEMU sifive_u machine. > >> > >> Looks like the MACB driver cannot find the correct MAC address. That > >> makes it rather awkward for network boot. > >> > >> Warning: ethernet@10090000 (eth0) using random MAC address - 0e:14:15:06:ae:e4 > > > > This is because we don't have place to put U-Boot environment > > variables as of now on Unleashed board. This will be solved once > > we have SPI driver and SPI_MMC driver for Unleased board. > > > > In future, we will be saving "ethaddr" environment variable on > > SPI_MMC so U-Boot will pick MAC address at boot-time from > > SPI_MMC. Once this is achieved, the above warning will go away. > > How is the MAC determined in Linux? In Linux, we have an "local-mac-address" DT property used by quite a few drivers (including Cadence Ethernet driver) but it's not uniform across Linux drivers. In U-Boot, another option is to change the Candence MACB driver and set "ethaddr" environment variable based on "local-mac-address" DT property from driver probe. Suggestions ?? Regards, Anup
> Am 12.02.2019 um 07:35 schrieb Anup Patel <anup@brainfault.org>: > >> On Tue, Feb 12, 2019 at 11:52 AM Alexander Graf <agraf@suse.de> wrote: >> >> >> >>>> Am 12.02.2019 um 03:57 schrieb Anup Patel <anup@brainfault.org>: >>>> >>>>> On Mon, Feb 11, 2019 at 9:07 PM Andreas Schwab <schwab@suse.de> wrote: >>>>> >>>>> On Feb 11 2019, Anup Patel <Anup.Patel@wdc.com> wrote: >>>>> >>>>> This patchset adds SiFive Freedom Unleashed (FU540) support >>>>> to RISC-V U-Boot. >>>>> >>>>> The patches are based upon latest U-Boot source tree >>>>> (git://git.denx.de/u-boot.git) at commit id >>>>> dbe70c7d4e3d5c705a98d82952e05a591efd0683 >>>>> >>>>> All drivers namely: SiFive PRCI, SiFive Serial, and Cadance >>>>> MACB Ethernet work fine on actual SiFive Unleashed board and >>>>> QEMU sifive_u machine. >>>> >>>> Looks like the MACB driver cannot find the correct MAC address. That >>>> makes it rather awkward for network boot. >>>> >>>> Warning: ethernet@10090000 (eth0) using random MAC address - 0e:14:15:06:ae:e4 >>> >>> This is because we don't have place to put U-Boot environment >>> variables as of now on Unleashed board. This will be solved once >>> we have SPI driver and SPI_MMC driver for Unleased board. >>> >>> In future, we will be saving "ethaddr" environment variable on >>> SPI_MMC so U-Boot will pick MAC address at boot-time from >>> SPI_MMC. Once this is achieved, the above warning will go away. >> >> How is the MAC determined in Linux? > > In Linux, we have an "local-mac-address" DT property used by > quite a few drivers (including Cadence Ethernet driver) but it's not > uniform across Linux drivers. > > In U-Boot, another option is to change the Candence MACB driver and > set "ethaddr" environment variable based on "local-mac-address" DT > property from driver probe. Suggestions ?? That would be my quick fix suggestion, yes :). Or do it in the board file. Alex > > Regards, > Anup
On Feb 12 2019, Anup Patel <anup@brainfault.org> wrote: > This is because we don't have place to put U-Boot environment > variables as of now on Unleashed board. This will be solved once > we have SPI driver and SPI_MMC driver for Unleased board. Isn't the MAC part of the initial DT? Andreas.
On Tue, Feb 12, 2019 at 4:34 PM Andreas Schwab <schwab@suse.de> wrote: > > On Feb 12 2019, Anup Patel <anup@brainfault.org> wrote: > > > This is because we don't have place to put U-Boot environment > > variables as of now on Unleashed board. This will be solved once > > we have SPI driver and SPI_MMC driver for Unleased board. > > Isn't the MAC part of the initial DT? > My understanding is that U-Boot should fixup the DT using the <ethaddr> environment value, before jumping to Linux. Regards, Bin
On Feb 12 2019, Bin Meng <bmeng.cn@gmail.com> wrote: > On Tue, Feb 12, 2019 at 4:34 PM Andreas Schwab <schwab@suse.de> wrote: >> >> On Feb 12 2019, Anup Patel <anup@brainfault.org> wrote: >> >> > This is because we don't have place to put U-Boot environment >> > variables as of now on Unleashed board. This will be solved once >> > we have SPI driver and SPI_MMC driver for Unleased board. >> >> Isn't the MAC part of the initial DT? >> > > My understanding is that U-Boot should fixup the DT using the > <ethaddr> environment value, before jumping to Linux. But where does it get the env var from? Why would it need to modify the MAC? Andreas.
On Tue, Feb 12, 2019 at 5:09 PM Andreas Schwab <schwab@suse.de> wrote: > > On Feb 12 2019, Bin Meng <bmeng.cn@gmail.com> wrote: > > > On Tue, Feb 12, 2019 at 4:34 PM Andreas Schwab <schwab@suse.de> wrote: > >> > >> On Feb 12 2019, Anup Patel <anup@brainfault.org> wrote: > >> > >> > This is because we don't have place to put U-Boot environment > >> > variables as of now on Unleashed board. This will be solved once > >> > we have SPI driver and SPI_MMC driver for Unleased board. > >> > >> Isn't the MAC part of the initial DT? > >> > > > > My understanding is that U-Boot should fixup the DT using the > > <ethaddr> environment value, before jumping to Linux. > > But where does it get the env var from? Why would it need to modify the > MAC? > The env var is stored in whatever supported media in U-Boot. Not like PCI NICs which normally have EEPROM to store pre-flashed MAC address by their vendors, for most embedded network controllers in the SoC, normally there is no hardware provided mechanism to ensure a unique MAC address, instead it relies on software to program one to the hardware before bringing it up. In the U-Boot case, it's the <ethaddr> env. Regards, Bin
On 02/12/2019 11:12 AM, Bin Meng wrote: > On Tue, Feb 12, 2019 at 5:09 PM Andreas Schwab <schwab@suse.de> wrote: >> On Feb 12 2019, Bin Meng <bmeng.cn@gmail.com> wrote: >> >>> On Tue, Feb 12, 2019 at 4:34 PM Andreas Schwab <schwab@suse.de> wrote: >>>> On Feb 12 2019, Anup Patel <anup@brainfault.org> wrote: >>>> >>>>> This is because we don't have place to put U-Boot environment >>>>> variables as of now on Unleashed board. This will be solved once >>>>> we have SPI driver and SPI_MMC driver for Unleased board. >>>> Isn't the MAC part of the initial DT? >>>> >>> My understanding is that U-Boot should fixup the DT using the >>> <ethaddr> environment value, before jumping to Linux. >> But where does it get the env var from? Why would it need to modify the >> MAC? >> > The env var is stored in whatever supported media in U-Boot. Not like > PCI NICs which normally have EEPROM to store pre-flashed MAC address > by their vendors, for most embedded network controllers in the SoC, > normally there is no hardware provided mechanism to ensure a unique > MAC address, instead it relies on software to program one to the > hardware before bringing it up. In the U-Boot case, it's the <ethaddr> > env. Yes, and U-Boot can read it from the DT to populate ethaddr if its upper layer does provide a stable MAC address through DT. Alex
On Feb 12 2019, Bin Meng <bmeng.cn@gmail.com> wrote: > The env var is stored in whatever supported media in U-Boot. Not like > PCI NICs which normally have EEPROM to store pre-flashed MAC address > by their vendors, for most embedded network controllers in the SoC, > normally there is no hardware provided mechanism to ensure a unique > MAC address, instead it relies on software to program one to the > hardware before bringing it up. On the Hifive the MAC is part of the initial DT, so there is no need to use a secondary store. Andreas.
On Tue, Feb 12, 2019 at 6:23 PM Andreas Schwab <schwab@suse.de> wrote: > > On Feb 12 2019, Bin Meng <bmeng.cn@gmail.com> wrote: > > > The env var is stored in whatever supported media in U-Boot. Not like > > PCI NICs which normally have EEPROM to store pre-flashed MAC address > > by their vendors, for most embedded network controllers in the SoC, > > normally there is no hardware provided mechanism to ensure a unique > > MAC address, instead it relies on software to program one to the > > hardware before bringing it up. > > On the Hifive the MAC is part of the initial DT, so there is no need to > use a secondary store. > So for the HiFive board, who is supposed to guarantee the uniqueness of the MAC address? Does SiFive program DT with different MAC to every board they shipped? If so, we can just read "local-mac-address" from DT in U-Boot. Regards, Bin
On Wed, Feb 13, 2019 at 7:01 AM Bin Meng <bmeng.cn@gmail.com> wrote: > > On Tue, Feb 12, 2019 at 6:23 PM Andreas Schwab <schwab@suse.de> wrote: > > > > On Feb 12 2019, Bin Meng <bmeng.cn@gmail.com> wrote: > > > > > The env var is stored in whatever supported media in U-Boot. Not like > > > PCI NICs which normally have EEPROM to store pre-flashed MAC address > > > by their vendors, for most embedded network controllers in the SoC, > > > normally there is no hardware provided mechanism to ensure a unique > > > MAC address, instead it relies on software to program one to the > > > hardware before bringing it up. > > > > On the Hifive the MAC is part of the initial DT, so there is no need to > > use a secondary store. > > > > So for the HiFive board, who is supposed to guarantee the uniqueness > of the MAC address? Does SiFive program DT with different MAC to every > board they shipped? If so, we can just read "local-mac-address" from > DT in U-Boot. General practice (atlease what I have seen on few boards), is that board will have unique MAC address printed/labelled for each Ethernet port. We can just set-and-save "ethaddr" U-Boot env variable based on MAC address printed on board. Unfortunately, I was not able to find printed MAC address on Unleashed board. Regards, Anup
On 13.02.19 02:31, Bin Meng wrote: > On Tue, Feb 12, 2019 at 6:23 PM Andreas Schwab <schwab@suse.de> wrote: >> >> On Feb 12 2019, Bin Meng <bmeng.cn@gmail.com> wrote: >> >>> The env var is stored in whatever supported media in U-Boot. Not like >>> PCI NICs which normally have EEPROM to store pre-flashed MAC address >>> by their vendors, for most embedded network controllers in the SoC, >>> normally there is no hardware provided mechanism to ensure a unique >>> MAC address, instead it relies on software to program one to the >>> hardware before bringing it up. >> >> On the Hifive the MAC is part of the initial DT, so there is no need to >> use a secondary store. >> > > So for the HiFive board, who is supposed to guarantee the uniqueness > of the MAC address? Does SiFive program DT with different MAC to every > board they shipped? If so, we can just read "local-mac-address" from > DT in U-Boot. The DT is supplied via SD card, just like U-Boot is. So it's up to the user to modify the DT and ensure that it contains a unique MAC address. Alex
On Feb 13 2019, Alexander Graf <agraf@suse.de> wrote:
> The DT is supplied via SD card
That's not true by default. It is part of the FSBL, I think.
Andreas.
On Feb 13 2019, Anup Patel <anup@brainfault.org> wrote: > General practice (atlease what I have seen on few boards), is that board > will have unique MAC address printed/labelled for each Ethernet port. We > can just set-and-save "ethaddr" U-Boot env variable based on MAC address > printed on board. > > Unfortunately, I was not able to find printed MAC address on Unleashed board. It is derived from the serial number. Andreas.
On Wed, 2019-02-13 at 10:35 +0100, Andreas Schwab wrote: > On Feb 13 2019, Anup Patel <anup@brainfault.org> wrote: > > > General practice (atlease what I have seen on few boards), is that > > board > > will have unique MAC address printed/labelled for each Ethernet > > port. We > > can just set-and-save "ethaddr" U-Boot env variable based on MAC > > address > > printed on board. > > > > Unfortunately, I was not able to find printed MAC address on > > Unleashed board. > > It is derived from the serial number. > Here is the relevant code from the FSBL [1]. The serial number is stored in OTP memory. There's also a U-Boot driver available [2], but I haven't tested or looked at it in detail. [1]: https://github.com/sifive/freedom-u540-c000-bootloader/blob/master/fsbl/main.c#L377 [2]: https://github.com/tmagik/HiFive_U-Boot/commit/6d842765de142b61f847852da7a9ce0d081d770c Thanks, Lukas
Hi Anup, Anup Patel <Anup.Patel@wdc.com> writes: > This patchset adds SiFive Freedom Unleashed (FU540) support > to RISC-V U-Boot. > > The patches are based upon latest U-Boot source tree > (git://git.denx.de/u-boot.git) at commit id > dbe70c7d4e3d5c705a98d82952e05a591efd0683 > > All drivers namely: SiFive PRCI, SiFive Serial, and Cadance > MACB Ethernet work fine on actual SiFive Unleashed board and > QEMU sifive_u machine. I tested u-boot networking (DHCP, TFTP) on my desk with a gigE switch and it worked fine. Then, I moved it to a lab with a 100Mb switch, and DHCP doesn't work anymore. Can you do some sanity testing with a 100Mb switch? Kevin
Kevin Hilman <khilman@baylibre.com> writes: > Hi Anup, > > Anup Patel <Anup.Patel@wdc.com> writes: > >> This patchset adds SiFive Freedom Unleashed (FU540) support >> to RISC-V U-Boot. >> >> The patches are based upon latest U-Boot source tree >> (git://git.denx.de/u-boot.git) at commit id >> dbe70c7d4e3d5c705a98d82952e05a591efd0683 >> >> All drivers namely: SiFive PRCI, SiFive Serial, and Cadance >> MACB Ethernet work fine on actual SiFive Unleashed board and >> QEMU sifive_u machine. > > I tested u-boot networking (DHCP, TFTP) on my desk with a gigE switch > and it worked fine. Then, I moved it to a lab with a 100Mb switch, > and DHCP doesn't work anymore. And to be clear, neither does TFTP if setting static ipaddr/netmask/gatewayip etc. Kevin
On Thu, Feb 14, 2019 at 7:58 AM Kevin Hilman <khilman@baylibre.com> wrote: > > Kevin Hilman <khilman@baylibre.com> writes: > > > Hi Anup, > > > > Anup Patel <Anup.Patel@wdc.com> writes: > > > >> This patchset adds SiFive Freedom Unleashed (FU540) support > >> to RISC-V U-Boot. > >> > >> The patches are based upon latest U-Boot source tree > >> (git://git.denx.de/u-boot.git) at commit id > >> dbe70c7d4e3d5c705a98d82952e05a591efd0683 > >> > >> All drivers namely: SiFive PRCI, SiFive Serial, and Cadance > >> MACB Ethernet work fine on actual SiFive Unleashed board and > >> QEMU sifive_u machine. > > > > I tested u-boot networking (DHCP, TFTP) on my desk with a gigE switch > > and it worked fine. Then, I moved it to a lab with a 100Mb switch, > > and DHCP doesn't work anymore. > > And to be clear, neither does TFTP if setting static > ipaddr/netmask/gatewayip etc. Sound to me a bug of the GEM driver on SiFive FU540 board. Regards, Bin
On Mon, 11 Mar 2019 07:33:25 PDT (-0700), bmeng.cn@gmail.com wrote: > On Thu, Feb 14, 2019 at 7:58 AM Kevin Hilman <khilman@baylibre.com> wrote: >> >> Kevin Hilman <khilman@baylibre.com> writes: >> >> > Hi Anup, >> > >> > Anup Patel <Anup.Patel@wdc.com> writes: >> > >> >> This patchset adds SiFive Freedom Unleashed (FU540) support >> >> to RISC-V U-Boot. >> >> >> >> The patches are based upon latest U-Boot source tree >> >> (git://git.denx.de/u-boot.git) at commit id >> >> dbe70c7d4e3d5c705a98d82952e05a591efd0683 >> >> >> >> All drivers namely: SiFive PRCI, SiFive Serial, and Cadance >> >> MACB Ethernet work fine on actual SiFive Unleashed board and >> >> QEMU sifive_u machine. >> > >> > I tested u-boot networking (DHCP, TFTP) on my desk with a gigE switch >> > and it worked fine. Then, I moved it to a lab with a 100Mb switch, >> > and DHCP doesn't work anymore. >> >> And to be clear, neither does TFTP if setting static >> ipaddr/netmask/gatewayip etc. > > Sound to me a bug of the GEM driver on SiFive FU540 board. It looks to me like u-boot is missing a driver for the GEM clockmux in the FU540. This is necessary to switch between the clock for 1G operation and 100M operation. Without this you'll just get whatever clock was set up by the previous boot stage (or even worse, reset).
Palmer, Anup, On Tue, Mar 12, 2019 at 1:55 AM Palmer Dabbelt <palmer@sifive.com> wrote: > > On Mon, 11 Mar 2019 07:33:25 PDT (-0700), bmeng.cn@gmail.com wrote: > > On Thu, Feb 14, 2019 at 7:58 AM Kevin Hilman <khilman@baylibre.com> wrote: > >> > >> Kevin Hilman <khilman@baylibre.com> writes: > >> > >> > Hi Anup, > >> > > >> > Anup Patel <Anup.Patel@wdc.com> writes: > >> > > >> >> This patchset adds SiFive Freedom Unleashed (FU540) support > >> >> to RISC-V U-Boot. > >> >> > >> >> The patches are based upon latest U-Boot source tree > >> >> (git://git.denx.de/u-boot.git) at commit id > >> >> dbe70c7d4e3d5c705a98d82952e05a591efd0683 > >> >> > >> >> All drivers namely: SiFive PRCI, SiFive Serial, and Cadance > >> >> MACB Ethernet work fine on actual SiFive Unleashed board and > >> >> QEMU sifive_u machine. > >> > > >> > I tested u-boot networking (DHCP, TFTP) on my desk with a gigE switch > >> > and it worked fine. Then, I moved it to a lab with a 100Mb switch, > >> > and DHCP doesn't work anymore. > >> > >> And to be clear, neither does TFTP if setting static > >> ipaddr/netmask/gatewayip etc. > > > > Sound to me a bug of the GEM driver on SiFive FU540 board. > > It looks to me like u-boot is missing a driver for the GEM clockmux in the > FU540. This is necessary to switch between the clock for 1G operation and 100M > operation. Without this you'll just get whatever clock was set up by the > previous boot stage (or even worse, reset). Anyone know if this is fixed in u-boot yet? I've yet to try the latest mainline u-boot, but will if if it's expected to work. Kevin
On 4/18/19 12:15 PM, Kevin Hilman wrote: > Palmer, Anup, > > On Tue, Mar 12, 2019 at 1:55 AM Palmer Dabbelt <palmer@sifive.com> wrote: >> >> On Mon, 11 Mar 2019 07:33:25 PDT (-0700), bmeng.cn@gmail.com wrote: >>> On Thu, Feb 14, 2019 at 7:58 AM Kevin Hilman <khilman@baylibre.com> wrote: >>>> >>>> Kevin Hilman <khilman@baylibre.com> writes: >>>> >>>>> Hi Anup, >>>>> >>>>> Anup Patel <Anup.Patel@wdc.com> writes: >>>>> >>>>>> This patchset adds SiFive Freedom Unleashed (FU540) support >>>>>> to RISC-V U-Boot. >>>>>> >>>>>> The patches are based upon latest U-Boot source tree >>>>>> (git://git.denx.de/u-boot.git) at commit id >>>>>> dbe70c7d4e3d5c705a98d82952e05a591efd0683 >>>>>> >>>>>> All drivers namely: SiFive PRCI, SiFive Serial, and Cadance >>>>>> MACB Ethernet work fine on actual SiFive Unleashed board and >>>>>> QEMU sifive_u machine. >>>>> >>>>> I tested u-boot networking (DHCP, TFTP) on my desk with a gigE switch >>>>> and it worked fine. Then, I moved it to a lab with a 100Mb switch, >>>>> and DHCP doesn't work anymore. >>>> >>>> And to be clear, neither does TFTP if setting static >>>> ipaddr/netmask/gatewayip etc. >>> >>> Sound to me a bug of the GEM driver on SiFive FU540 board. >> >> It looks to me like u-boot is missing a driver for the GEM clockmux in the >> FU540. This is necessary to switch between the clock for 1G operation and 100M >> operation. Without this you'll just get whatever clock was set up by the >> previous boot stage (or even worse, reset). > > Anyone know if this is fixed in u-boot yet? I've yet to try the > latest mainline u-boot, but will if if it's expected to work. > I have not seen a GEM driver for FU540 board. So I guess it is not fixed it. Is it a blocker for setting up kernelCI for RISC-V ? Regards, Atish > Kevin > _______________________________________________ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot >
Atish Patra <atish.patra@wdc.com> writes: > On 4/18/19 12:15 PM, Kevin Hilman wrote: >> Palmer, Anup, >> >> On Tue, Mar 12, 2019 at 1:55 AM Palmer Dabbelt <palmer@sifive.com> wrote: >>> >>> On Mon, 11 Mar 2019 07:33:25 PDT (-0700), bmeng.cn@gmail.com wrote: >>>> On Thu, Feb 14, 2019 at 7:58 AM Kevin Hilman <khilman@baylibre.com> wrote: >>>>> >>>>> Kevin Hilman <khilman@baylibre.com> writes: >>>>> >>>>>> Hi Anup, >>>>>> >>>>>> Anup Patel <Anup.Patel@wdc.com> writes: >>>>>> >>>>>>> This patchset adds SiFive Freedom Unleashed (FU540) support >>>>>>> to RISC-V U-Boot. >>>>>>> >>>>>>> The patches are based upon latest U-Boot source tree >>>>>>> (git://git.denx.de/u-boot.git) at commit id >>>>>>> dbe70c7d4e3d5c705a98d82952e05a591efd0683 >>>>>>> >>>>>>> All drivers namely: SiFive PRCI, SiFive Serial, and Cadance >>>>>>> MACB Ethernet work fine on actual SiFive Unleashed board and >>>>>>> QEMU sifive_u machine. >>>>>> >>>>>> I tested u-boot networking (DHCP, TFTP) on my desk with a gigE switch >>>>>> and it worked fine. Then, I moved it to a lab with a 100Mb switch, >>>>>> and DHCP doesn't work anymore. >>>>> >>>>> And to be clear, neither does TFTP if setting static >>>>> ipaddr/netmask/gatewayip etc. >>>> >>>> Sound to me a bug of the GEM driver on SiFive FU540 board. >>> >>> It looks to me like u-boot is missing a driver for the GEM clockmux in the >>> FU540. This is necessary to switch between the clock for 1G operation and 100M >>> operation. Without this you'll just get whatever clock was set up by the >>> previous boot stage (or even worse, reset). >> >> Anyone know if this is fixed in u-boot yet? I've yet to try the >> latest mainline u-boot, but will if if it's expected to work. >> > > I have not seen a GEM driver for FU540 board. So I guess it is not fixed > it. Is it a blocker for setting up kernelCI for RISC-V ? Not really, that's only one of the remaining issue. For now, I have connected it to a gigE switch, so u-boot networking is working. But, the bigger blocker for kernelCI right now is not having out-of-the-box mainline support. Mainline is still missing a serial driver, and a handful of Kconfig options in the default defconfig to make things boot[1]. If I use the 'v5.1-rc4_unleashed' from your github, along with my kconfig fragment[1], things are working well. But in order to automate this for kernelCI, we need all of that upstream. Kevin [1] This is the config fragment I'm adding to the default defconfig in mainline. I'm not exactly sure which ones are absolutely need for basic boot. CONFIG_SERIAL_SIFIVE=y CONFIG_SERIAL_SIFIVE_CONSOLE=y CONFIG_SIFIVE_PLIC=y CONFIG_SPI=y CONFIG_SPI_SIFIVE=y CONFIG_GPIOLIB=y CONFIG_GPIO_SIFIVE=y CONFIG_PWM_SIFIVE=y CONFIG_CLK_U54_PRCI=y CONFIG_CLK_GEMGXL_MGMT=y
On 4/18/19 4:16 PM, Kevin Hilman wrote: > Atish Patra <atish.patra@wdc.com> writes: > >> On 4/18/19 12:15 PM, Kevin Hilman wrote: >>> Palmer, Anup, >>> >>> On Tue, Mar 12, 2019 at 1:55 AM Palmer Dabbelt <palmer@sifive.com> wrote: >>>> >>>> On Mon, 11 Mar 2019 07:33:25 PDT (-0700), bmeng.cn@gmail.com wrote: >>>>> On Thu, Feb 14, 2019 at 7:58 AM Kevin Hilman <khilman@baylibre.com> wrote: >>>>>> >>>>>> Kevin Hilman <khilman@baylibre.com> writes: >>>>>> >>>>>>> Hi Anup, >>>>>>> >>>>>>> Anup Patel <Anup.Patel@wdc.com> writes: >>>>>>> >>>>>>>> This patchset adds SiFive Freedom Unleashed (FU540) support >>>>>>>> to RISC-V U-Boot. >>>>>>>> >>>>>>>> The patches are based upon latest U-Boot source tree >>>>>>>> (git://git.denx.de/u-boot.git) at commit id >>>>>>>> dbe70c7d4e3d5c705a98d82952e05a591efd0683 >>>>>>>> >>>>>>>> All drivers namely: SiFive PRCI, SiFive Serial, and Cadance >>>>>>>> MACB Ethernet work fine on actual SiFive Unleashed board and >>>>>>>> QEMU sifive_u machine. >>>>>>> >>>>>>> I tested u-boot networking (DHCP, TFTP) on my desk with a gigE switch >>>>>>> and it worked fine. Then, I moved it to a lab with a 100Mb switch, >>>>>>> and DHCP doesn't work anymore. >>>>>> >>>>>> And to be clear, neither does TFTP if setting static >>>>>> ipaddr/netmask/gatewayip etc. >>>>> >>>>> Sound to me a bug of the GEM driver on SiFive FU540 board. >>>> >>>> It looks to me like u-boot is missing a driver for the GEM clockmux in the >>>> FU540. This is necessary to switch between the clock for 1G operation and 100M >>>> operation. Without this you'll just get whatever clock was set up by the >>>> previous boot stage (or even worse, reset). >>> >>> Anyone know if this is fixed in u-boot yet? I've yet to try the >>> latest mainline u-boot, but will if if it's expected to work. >>> >> >> I have not seen a GEM driver for FU540 board. So I guess it is not fixed >> it. Is it a blocker for setting up kernelCI for RISC-V ? > > Not really, that's only one of the remaining issue. For now, I have > connected it to a gigE switch, so u-boot networking is working. > > But, the bigger blocker for kernelCI right now is not having > out-of-the-box mainline support. Mainline is still missing a serial > driver, and a handful of Kconfig options in the default defconfig to > make things boot[1]. > > If I use the 'v5.1-rc4_unleashed' from your github, along with my > kconfig fragment[1], things are working well. > > But in order to automate this for kernelCI, we need all of that > upstream. > Yeah. I agree. We need upstream drivers sooner than later. I believe SiFive Team (Paul & co) are working on this. He recently sent updated version of driver patches to the linux-riscv mailing list. > Kevin > > [1] This is the config fragment I'm adding to the default defconfig in > mainline. I'm not exactly sure which ones are absolutely need for basic > boot. > > CONFIG_SERIAL_SIFIVE=y > CONFIG_SERIAL_SIFIVE_CONSOLE=y > CONFIG_SIFIVE_PLIC=y > CONFIG_SPI=y > CONFIG_SPI_SIFIVE=y > CONFIG_GPIOLIB=y > CONFIG_GPIO_SIFIVE=y > CONFIG_PWM_SIFIVE=y > CONFIG_CLK_U54_PRCI=y > CONFIG_CLK_GEMGXL_MGMT=y > My working config has enabled all of the above except CONFIG_PWM_SIFIVE. I have not played around the config that much to find out absolute minimum config. So this may not be the answer you are looking for :). Regards, Atish
Atish Patra <atish.patra@wdc.com> writes: > On 4/18/19 4:16 PM, Kevin Hilman wrote: >> Atish Patra <atish.patra@wdc.com> writes: >> >>> On 4/18/19 12:15 PM, Kevin Hilman wrote: >>>> Palmer, Anup, >>>> >>>> On Tue, Mar 12, 2019 at 1:55 AM Palmer Dabbelt <palmer@sifive.com> wrote: >>>>> >>>>> On Mon, 11 Mar 2019 07:33:25 PDT (-0700), bmeng.cn@gmail.com wrote: >>>>>> On Thu, Feb 14, 2019 at 7:58 AM Kevin Hilman <khilman@baylibre.com> wrote: >>>>>>> >>>>>>> Kevin Hilman <khilman@baylibre.com> writes: >>>>>>> >>>>>>>> Hi Anup, >>>>>>>> >>>>>>>> Anup Patel <Anup.Patel@wdc.com> writes: >>>>>>>> >>>>>>>>> This patchset adds SiFive Freedom Unleashed (FU540) support >>>>>>>>> to RISC-V U-Boot. >>>>>>>>> >>>>>>>>> The patches are based upon latest U-Boot source tree >>>>>>>>> (git://git.denx.de/u-boot.git) at commit id >>>>>>>>> dbe70c7d4e3d5c705a98d82952e05a591efd0683 >>>>>>>>> >>>>>>>>> All drivers namely: SiFive PRCI, SiFive Serial, and Cadance >>>>>>>>> MACB Ethernet work fine on actual SiFive Unleashed board and >>>>>>>>> QEMU sifive_u machine. >>>>>>>> >>>>>>>> I tested u-boot networking (DHCP, TFTP) on my desk with a gigE switch >>>>>>>> and it worked fine. Then, I moved it to a lab with a 100Mb switch, >>>>>>>> and DHCP doesn't work anymore. >>>>>>> >>>>>>> And to be clear, neither does TFTP if setting static >>>>>>> ipaddr/netmask/gatewayip etc. >>>>>> >>>>>> Sound to me a bug of the GEM driver on SiFive FU540 board. >>>>> >>>>> It looks to me like u-boot is missing a driver for the GEM clockmux in the >>>>> FU540. This is necessary to switch between the clock for 1G operation and 100M >>>>> operation. Without this you'll just get whatever clock was set up by the >>>>> previous boot stage (or even worse, reset). >>>> >>>> Anyone know if this is fixed in u-boot yet? I've yet to try the >>>> latest mainline u-boot, but will if if it's expected to work. >>>> >>> >>> I have not seen a GEM driver for FU540 board. So I guess it is not fixed >>> it. Is it a blocker for setting up kernelCI for RISC-V ? >> >> Not really, that's only one of the remaining issue. For now, I have >> connected it to a gigE switch, so u-boot networking is working. >> >> But, the bigger blocker for kernelCI right now is not having >> out-of-the-box mainline support. Mainline is still missing a serial >> driver, and a handful of Kconfig options in the default defconfig to >> make things boot[1]. >> >> If I use the 'v5.1-rc4_unleashed' from your github, along with my >> kconfig fragment[1], things are working well. >> >> But in order to automate this for kernelCI, we need all of that >> upstream. >> > Yeah. I agree. We need upstream drivers sooner than later. > I believe SiFive Team (Paul & co) are working on this. > > He recently sent updated version of driver patches to the linux-riscv > mailing list. Yes, I'm trying to test all of those (hence our other discussion on the DT thread) >> [1] This is the config fragment I'm adding to the default defconfig in >> mainline. I'm not exactly sure which ones are absolutely need for basic >> boot. >> >> CONFIG_SERIAL_SIFIVE=y >> CONFIG_SERIAL_SIFIVE_CONSOLE=y >> CONFIG_SIFIVE_PLIC=y >> CONFIG_SPI=y >> CONFIG_SPI_SIFIVE=y >> CONFIG_GPIOLIB=y >> CONFIG_GPIO_SIFIVE=y >> CONFIG_PWM_SIFIVE=y >> CONFIG_CLK_U54_PRCI=y >> CONFIG_CLK_GEMGXL_MGMT=y >> > > My working config has enabled all of the above except CONFIG_PWM_SIFIVE. > I have not played around the config that much to find out absolute > minimum config. So this may not be the answer you are looking for :). At least for kernelCI, we'll need to figure that out and get it upstream if we want to boot test these. Kevin
On Fri, Apr 19, 2019 at 1:38 PM Kevin Hilman <khilman@baylibre.com> wrote: > > Atish Patra <atish.patra@wdc.com> writes: > > > On 4/18/19 4:16 PM, Kevin Hilman wrote: > >> Atish Patra <atish.patra@wdc.com> writes: > >> > >>> On 4/18/19 12:15 PM, Kevin Hilman wrote: > >>>> Palmer, Anup, > >>>> > >>>> On Tue, Mar 12, 2019 at 1:55 AM Palmer Dabbelt <palmer@sifive.com> wrote: > >>>>> > >>>>> On Mon, 11 Mar 2019 07:33:25 PDT (-0700), bmeng.cn@gmail.com wrote: > >>>>>> On Thu, Feb 14, 2019 at 7:58 AM Kevin Hilman <khilman@baylibre.com> wrote: > >>>>>>> > >>>>>>> Kevin Hilman <khilman@baylibre.com> writes: > >>>>>>> > >>>>>>>> Hi Anup, > >>>>>>>> > >>>>>>>> Anup Patel <Anup.Patel@wdc.com> writes: > >>>>>>>> > >>>>>>>>> This patchset adds SiFive Freedom Unleashed (FU540) support > >>>>>>>>> to RISC-V U-Boot. > >>>>>>>>> > >>>>>>>>> The patches are based upon latest U-Boot source tree > >>>>>>>>> (git://git.denx.de/u-boot.git) at commit id > >>>>>>>>> dbe70c7d4e3d5c705a98d82952e05a591efd0683 > >>>>>>>>> > >>>>>>>>> All drivers namely: SiFive PRCI, SiFive Serial, and Cadance > >>>>>>>>> MACB Ethernet work fine on actual SiFive Unleashed board and > >>>>>>>>> QEMU sifive_u machine. > >>>>>>>> > >>>>>>>> I tested u-boot networking (DHCP, TFTP) on my desk with a gigE switch > >>>>>>>> and it worked fine. Then, I moved it to a lab with a 100Mb switch, > >>>>>>>> and DHCP doesn't work anymore. > >>>>>>> > >>>>>>> And to be clear, neither does TFTP if setting static > >>>>>>> ipaddr/netmask/gatewayip etc. > >>>>>> > >>>>>> Sound to me a bug of the GEM driver on SiFive FU540 board. > >>>>> > >>>>> It looks to me like u-boot is missing a driver for the GEM clockmux in the > >>>>> FU540. This is necessary to switch between the clock for 1G operation and 100M > >>>>> operation. Without this you'll just get whatever clock was set up by the > >>>>> previous boot stage (or even worse, reset). > >>>> > >>>> Anyone know if this is fixed in u-boot yet? I've yet to try the > >>>> latest mainline u-boot, but will if if it's expected to work. > >>>> > >>> > >>> I have not seen a GEM driver for FU540 board. So I guess it is not fixed > >>> it. Is it a blocker for setting up kernelCI for RISC-V ? > >> > >> Not really, that's only one of the remaining issue. For now, I have > >> connected it to a gigE switch, so u-boot networking is working. > >> > >> But, the bigger blocker for kernelCI right now is not having > >> out-of-the-box mainline support. Mainline is still missing a serial > >> driver, and a handful of Kconfig options in the default defconfig to > >> make things boot[1]. > >> > >> If I use the 'v5.1-rc4_unleashed' from your github, along with my > >> kconfig fragment[1], things are working well. > >> > >> But in order to automate this for kernelCI, we need all of that > >> upstream. > >> > > Yeah. I agree. We need upstream drivers sooner than later. > > I believe SiFive Team (Paul & co) are working on this. > > > > He recently sent updated version of driver patches to the linux-riscv > > mailing list. > > Yes, I'm trying to test all of those (hence our other discussion on the > DT thread) > > >> [1] This is the config fragment I'm adding to the default defconfig in > >> mainline. I'm not exactly sure which ones are absolutely need for basic > >> boot. > >> > >> CONFIG_SERIAL_SIFIVE=y > >> CONFIG_SERIAL_SIFIVE_CONSOLE=y > >> CONFIG_SIFIVE_PLIC=y > >> CONFIG_SPI=y > >> CONFIG_SPI_SIFIVE=y > >> CONFIG_GPIOLIB=y > >> CONFIG_GPIO_SIFIVE=y > >> CONFIG_PWM_SIFIVE=y > >> CONFIG_CLK_U54_PRCI=y > >> CONFIG_CLK_GEMGXL_MGMT=y > >> > > > > My working config has enabled all of the above except CONFIG_PWM_SIFIVE. > > I have not played around the config that much to find out absolute > > minimum config. So this may not be the answer you are looking for :). > > At least for kernelCI, we'll need to figure that out and get it upstream > if we want to boot test these. Oh, and one other u-boot question. Any reason you didn't enable `booti` support in riscv u-boot? That would allow you to boot the Image (or Image.gz) directly, instead of the need to create a special image with u-boot header (uImage) Kevin
On 4/19/19 1:44 PM, Kevin Hilman wrote: > On Fri, Apr 19, 2019 at 1:38 PM Kevin Hilman <khilman@baylibre.com> wrote: >> >> Atish Patra <atish.patra@wdc.com> writes: >> >>> On 4/18/19 4:16 PM, Kevin Hilman wrote: >>>> Atish Patra <atish.patra@wdc.com> writes: >>>> >>>>> On 4/18/19 12:15 PM, Kevin Hilman wrote: >>>>>> Palmer, Anup, >>>>>> >>>>>> On Tue, Mar 12, 2019 at 1:55 AM Palmer Dabbelt <palmer@sifive.com> wrote: >>>>>>> >>>>>>> On Mon, 11 Mar 2019 07:33:25 PDT (-0700), bmeng.cn@gmail.com wrote: >>>>>>>> On Thu, Feb 14, 2019 at 7:58 AM Kevin Hilman <khilman@baylibre.com> wrote: >>>>>>>>> >>>>>>>>> Kevin Hilman <khilman@baylibre.com> writes: >>>>>>>>> >>>>>>>>>> Hi Anup, >>>>>>>>>> >>>>>>>>>> Anup Patel <Anup.Patel@wdc.com> writes: >>>>>>>>>> >>>>>>>>>>> This patchset adds SiFive Freedom Unleashed (FU540) support >>>>>>>>>>> to RISC-V U-Boot. >>>>>>>>>>> >>>>>>>>>>> The patches are based upon latest U-Boot source tree >>>>>>>>>>> (git://git.denx.de/u-boot.git) at commit id >>>>>>>>>>> dbe70c7d4e3d5c705a98d82952e05a591efd0683 >>>>>>>>>>> >>>>>>>>>>> All drivers namely: SiFive PRCI, SiFive Serial, and Cadance >>>>>>>>>>> MACB Ethernet work fine on actual SiFive Unleashed board and >>>>>>>>>>> QEMU sifive_u machine. >>>>>>>>>> >>>>>>>>>> I tested u-boot networking (DHCP, TFTP) on my desk with a gigE switch >>>>>>>>>> and it worked fine. Then, I moved it to a lab with a 100Mb switch, >>>>>>>>>> and DHCP doesn't work anymore. >>>>>>>>> >>>>>>>>> And to be clear, neither does TFTP if setting static >>>>>>>>> ipaddr/netmask/gatewayip etc. >>>>>>>> >>>>>>>> Sound to me a bug of the GEM driver on SiFive FU540 board. >>>>>>> >>>>>>> It looks to me like u-boot is missing a driver for the GEM clockmux in the >>>>>>> FU540. This is necessary to switch between the clock for 1G operation and 100M >>>>>>> operation. Without this you'll just get whatever clock was set up by the >>>>>>> previous boot stage (or even worse, reset). >>>>>> >>>>>> Anyone know if this is fixed in u-boot yet? I've yet to try the >>>>>> latest mainline u-boot, but will if if it's expected to work. >>>>>> >>>>> >>>>> I have not seen a GEM driver for FU540 board. So I guess it is not fixed >>>>> it. Is it a blocker for setting up kernelCI for RISC-V ? >>>> >>>> Not really, that's only one of the remaining issue. For now, I have >>>> connected it to a gigE switch, so u-boot networking is working. >>>> >>>> But, the bigger blocker for kernelCI right now is not having >>>> out-of-the-box mainline support. Mainline is still missing a serial >>>> driver, and a handful of Kconfig options in the default defconfig to >>>> make things boot[1]. >>>> >>>> If I use the 'v5.1-rc4_unleashed' from your github, along with my >>>> kconfig fragment[1], things are working well. >>>> >>>> But in order to automate this for kernelCI, we need all of that >>>> upstream. >>>> >>> Yeah. I agree. We need upstream drivers sooner than later. >>> I believe SiFive Team (Paul & co) are working on this. >>> >>> He recently sent updated version of driver patches to the linux-riscv >>> mailing list. >> >> Yes, I'm trying to test all of those (hence our other discussion on the >> DT thread) >> >>>> [1] This is the config fragment I'm adding to the default defconfig in >>>> mainline. I'm not exactly sure which ones are absolutely need for basic >>>> boot. >>>> >>>> CONFIG_SERIAL_SIFIVE=y >>>> CONFIG_SERIAL_SIFIVE_CONSOLE=y >>>> CONFIG_SIFIVE_PLIC=y >>>> CONFIG_SPI=y >>>> CONFIG_SPI_SIFIVE=y >>>> CONFIG_GPIOLIB=y >>>> CONFIG_GPIO_SIFIVE=y >>>> CONFIG_PWM_SIFIVE=y >>>> CONFIG_CLK_U54_PRCI=y >>>> CONFIG_CLK_GEMGXL_MGMT=y >>>> >>> >>> My working config has enabled all of the above except CONFIG_PWM_SIFIVE. >>> I have not played around the config that much to find out absolute >>> minimum config. So this may not be the answer you are looking for :). >> >> At least for kernelCI, we'll need to figure that out and get it upstream >> if we want to boot test these. > > Oh, and one other u-boot question. > > Any reason you didn't enable `booti` support in riscv u-boot? That > would allow you to boot the Image (or Image.gz) directly, instead of > the need to create a special image with u-boot header (uImage) > Yes. I am currently working on booti support. I should have a working patch by next week. Regards, Atish > Kevin >