[U-Boot] [PATCH v7 00/15] SiFive FU540 Support

Atish Patra atish.patra at wdc.com
Sat Apr 20 02:56:31 UTC 2019


On 4/19/19 1:44 PM, Kevin Hilman wrote:
> On Fri, Apr 19, 2019 at 1:38 PM Kevin Hilman <khilman at baylibre.com> wrote:
>>
>> Atish Patra <atish.patra at wdc.com> writes:
>>
>>> On 4/18/19 4:16 PM, Kevin Hilman wrote:
>>>> Atish Patra <atish.patra at 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 at sifive.com> wrote:
>>>>>>>
>>>>>>> On Mon, 11 Mar 2019 07:33:25 PDT (-0700), bmeng.cn at gmail.com wrote:
>>>>>>>> On Thu, Feb 14, 2019 at 7:58 AM Kevin Hilman <khilman at baylibre.com> wrote:
>>>>>>>>>
>>>>>>>>> Kevin Hilman <khilman at baylibre.com> writes:
>>>>>>>>>
>>>>>>>>>> Hi Anup,
>>>>>>>>>>
>>>>>>>>>> Anup Patel <Anup.Patel at 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
> 



More information about the U-Boot mailing list