[U-Boot,v7,00/15] SiFive FU540 Support
mbox series

Message ID 20190211054030.21393-1-anup.patel@wdc.com
Headers show
Series
  • SiFive FU540 Support
Related show

Message

Anup Patel Feb. 11, 2019, 5:41 a.m. UTC
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

Comments

Andreas Schwab Feb. 11, 2019, 3:37 p.m. UTC | #1
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.
Anup Patel Feb. 12, 2019, 2:57 a.m. UTC | #2
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
Alexander Graf Feb. 12, 2019, 6:22 a.m. UTC | #3
> 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
Anup Patel Feb. 12, 2019, 6:35 a.m. UTC | #4
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
Alexander Graf Feb. 12, 2019, 7 a.m. UTC | #5
> 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
Andreas Schwab Feb. 12, 2019, 8:34 a.m. UTC | #6
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.
Bin Meng Feb. 12, 2019, 8:35 a.m. UTC | #7
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
Andreas Schwab Feb. 12, 2019, 9:09 a.m. UTC | #8
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.
Bin Meng Feb. 12, 2019, 10:12 a.m. UTC | #9
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
Alexander Graf Feb. 12, 2019, 10:16 a.m. UTC | #10
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
Andreas Schwab Feb. 12, 2019, 10:22 a.m. UTC | #11
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.
Bin Meng Feb. 13, 2019, 1:31 a.m. UTC | #12
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
Anup Patel Feb. 13, 2019, 3:51 a.m. UTC | #13
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
Alexander Graf Feb. 13, 2019, 8:29 a.m. UTC | #14
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
Andreas Schwab Feb. 13, 2019, 9:34 a.m. UTC | #15
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.
Andreas Schwab Feb. 13, 2019, 9:35 a.m. UTC | #16
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.
Auer, Lukas Feb. 13, 2019, 9:46 a.m. UTC | #17
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
Kevin Hilman Feb. 13, 2019, 11:44 p.m. UTC | #18
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 Feb. 13, 2019, 11:58 p.m. UTC | #19
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
Bin Meng March 11, 2019, 2:33 p.m. UTC | #20
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
Palmer Dabbelt March 12, 2019, 8:55 a.m. UTC | #21
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).
Kevin Hilman April 18, 2019, 7:14 p.m. UTC | #22
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
Atish Patra April 18, 2019, 8:05 p.m. UTC | #23
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
>
Kevin Hilman April 18, 2019, 11:16 p.m. UTC | #24
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
Atish Patra April 19, 2019, 12:51 a.m. UTC | #25
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
Kevin Hilman April 19, 2019, 8:38 p.m. UTC | #26
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
Kevin Hilman April 19, 2019, 8:43 p.m. UTC | #27
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
Atish Patra April 20, 2019, 2:56 a.m. UTC | #28
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
>