From mboxrd@z Thu Jan 1 00:00:00 1970 From: Atish Patra Date: Fri, 19 Apr 2019 19:56:31 -0700 Subject: [U-Boot] [PATCH v7 00/15] SiFive FU540 Support In-Reply-To: References: <875379d7-4127-40f0-c0e0-0d4c2e4c9dba@wdc.com> <7hzhomewfy.fsf@baylibre.com> <7himv9buid.fsf@baylibre.com> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 4/19/19 1:44 PM, Kevin Hilman wrote: > On Fri, Apr 19, 2019 at 1:38 PM Kevin Hilman wrote: >> >> Atish Patra writes: >> >>> On 4/18/19 4:16 PM, Kevin Hilman wrote: >>>> Atish Patra writes: >>>> >>>>> On 4/18/19 12:15 PM, Kevin Hilman wrote: >>>>>> Palmer, Anup, >>>>>> >>>>>> On Tue, Mar 12, 2019 at 1:55 AM Palmer Dabbelt 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 wrote: >>>>>>>>> >>>>>>>>> Kevin Hilman writes: >>>>>>>>> >>>>>>>>>> Hi Anup, >>>>>>>>>> >>>>>>>>>> Anup Patel 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 >