| 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 >
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. Changes since v6: - Rebased patches to latest U-Boot source tree - Droped PATCH1 and PATCH2. Instead added a PATCH to select CREATE_ARCH_SYMLINK for RISC-V - Few typo fixes in SiFive FU540 readme Changes since v5: - Added PATCH16 to fix INITRD passing to Linux using bootm for U-Boot RISC-V Changes since v4: - Removed #ifndef from macb_enable_clk() in PATCH7 - Updated test/dm/clk.c in PATCH10 to test fixed factor clock using sandbox Changes since v3: - Added patch to un-ignore arch/riscv/include/asm/arch - Added patch to fix mrproper make target to only remove arch/*/include/asm/arch paths which are symlinks - Added patch to have place-holder asm/arch/clk.h for RISC-V - Removed "#ifndef CONFIG_RISCV" from macb clk API patch Changes since v2: - Fixed typo in PATCH3 comments - Removed "#if" from clk_fixed_factor_ofdata_to_platdata() in PATCH7 - Added PATCH12 for SiFive FU540 README guide Changes since v1: - Re-ordered SoB in patches with multiple SoB - Simplified board_get_usable_ram_top() added by PATCH3 Anup Patel (10): riscv: Enable create symlink using kconfig riscv: Rename cpu/qemu to cpu/generic riscv: Add asm/dma-mapping.h for DMA mappings riscv: Add place-holder asm/arch/clk.h for driver compilation riscv: generic: Ensure that U-Boot runs within 4GB for 64bit systems net: macb: Fix clk API usage for RISC-V systems clk: Add SiFive FU540 PRCI clock driver clk: Add fixed-factor clock driver riscv: Add SiFive FU540 board support riscv: Enable CONFIG_SYS_BOOT_RAMDISK_HIGH for using initrd Atish Patra (5): net: macb: Fix GEM hardware detection drivers: serial_sifive: Fix baud rate calculation drivers: serial_sifive: Skip baudrate config if no input clock cpu: Bind timer driver for boot hart doc: Add a readme guide for SiFive FU540 arch/Kconfig | 1 + arch/riscv/Kconfig | 6 +- arch/riscv/cpu/{qemu => generic}/Kconfig | 2 +- arch/riscv/cpu/{qemu => generic}/Makefile | 0 arch/riscv/cpu/{qemu => generic}/cpu.c | 0 arch/riscv/cpu/generic/dram.c | 37 ++ arch/riscv/cpu/qemu/dram.c | 17 - arch/riscv/include/asm/arch-generic/clk.h | 14 + arch/riscv/include/asm/config.h | 1 + arch/riscv/include/asm/dma-mapping.h | 38 ++ arch/sandbox/dts/test.dts | 8 + board/emulation/qemu-riscv/Kconfig | 4 +- .../qemu-riscv => sifive/fu540}/Kconfig | 36 +- board/sifive/fu540/MAINTAINERS | 9 + board/sifive/fu540/Makefile | 5 + board/sifive/fu540/fu540.c | 17 + configs/sifive_fu540_defconfig | 11 + doc/README.sifive-fu540 | 303 +++++++++ drivers/clk/Kconfig | 1 + drivers/clk/Makefile | 5 +- drivers/clk/clk_fixed_factor.c | 72 +++ drivers/clk/sifive/Kconfig | 19 + drivers/clk/sifive/Makefile | 5 + .../clk/sifive/analogbits-wrpll-cln28hpc.h | 101 +++ drivers/clk/sifive/fu540-prci.c | 604 ++++++++++++++++++ drivers/clk/sifive/wrpll-cln28hpc.c | 390 +++++++++++ drivers/cpu/riscv_cpu.c | 7 +- drivers/net/macb.c | 11 +- drivers/serial/serial_sifive.c | 60 +- include/configs/sifive-fu540.h | 43 ++ include/dt-bindings/clk/sifive-fu540-prci.h | 29 + test/dm/clk.c | 5 +- 32 files changed, 1795 insertions(+), 66 deletions(-) rename arch/riscv/cpu/{qemu => generic}/Kconfig (91%) rename arch/riscv/cpu/{qemu => generic}/Makefile (100%) rename arch/riscv/cpu/{qemu => generic}/cpu.c (100%) create mode 100644 arch/riscv/cpu/generic/dram.c delete mode 100644 arch/riscv/cpu/qemu/dram.c create mode 100644 arch/riscv/include/asm/arch-generic/clk.h create mode 100644 arch/riscv/include/asm/dma-mapping.h copy board/{emulation/qemu-riscv => sifive/fu540}/Kconfig (57%) create mode 100644 board/sifive/fu540/MAINTAINERS create mode 100644 board/sifive/fu540/Makefile create mode 100644 board/sifive/fu540/fu540.c create mode 100644 configs/sifive_fu540_defconfig create mode 100644 doc/README.sifive-fu540 create mode 100644 drivers/clk/clk_fixed_factor.c create mode 100644 drivers/clk/sifive/Kconfig create mode 100644 drivers/clk/sifive/Makefile create mode 100644 drivers/clk/sifive/analogbits-wrpll-cln28hpc.h create mode 100644 drivers/clk/sifive/fu540-prci.c create mode 100644 drivers/clk/sifive/wrpll-cln28hpc.c create mode 100644 include/configs/sifive-fu540.h create mode 100644 include/dt-bindings/clk/sifive-fu540-prci.h