[U-Boot] [PATCH v7 14/15] doc: Add a readme guide for SiFive FU540
Atish Patra
Atish.Patra at wdc.com
Wed Feb 13 01:31:27 UTC 2019
> On Feb 12, 2019, at 4:18 PM, Kevin Hilman <khilman at baylibre.com> wrote:
>
> Anup Patel <Anup.Patel at wdc.com> writes:
>
>> From: Atish Patra <atish.patra at wdc.com>
>>
>> The readme guide describes the procedure to build, flash and boot Linux
>> using U-Boot on HiFive Unleashed. It also explains the current state of
>> U-boot support and future action items.
>>
>> Signed-off-by: Atish Patra <atish.patra at wdc.com>
>> Signed-off-by: Anup Patel <anup.patel at wdc.com>
>> Reviewed-by: Lukas Auer <lukas.auer at aisec.fraunhofer.de>
>
> I'm testing this with the mainline kernel (v5.0-rc6) and running into
> some problems getting kernel output on the serial console.
>
Unfortunately.
> [...]
>
>> +=> setenv ethaddr 70:B3:D5:92:F0:C2
>> +=> setenv ipaddr 10.196.157.189
>> +=> setenv serverip 10.11.143.218
>> +=> setenv gatewayip 10.196.156.1
>> +=> setenv netmask 255.255.252.0
>> +=> bdinfo
>> +boot_params = 0x0000000000000000
>> +DRAM bank = 0x0000000000000000
>> +-> start = 0x0000000080000000
>> +-> size = 0x0000000200000000
>> +relocaddr = 0x00000000fff90000
>> +reloc off = 0x000000007fd90000
>> +ethaddr = 70:B3:D5:92:F0:C2
>> +IP addr = 10.196.157.189
>> +baudrate = 115200 bps
>> +=> tftpboot uImage
>> +ethernet at 10090000: PHY present at 0
>> +ethernet at 10090000: Starting autonegotiation...
>> +ethernet at 10090000: Autonegotiation complete
>> +ethernet at 10090000: link up, 1000Mbps full-duplex (lpa: 0x3800)
>> +Using ethernet at 10090000 device
>> +TFTP from server 10.11.143.218; our IP address is 10.196.157.189; sending through gateway 10.196.156.1
>> +Filename 'uImage'.
>> +Load address: 0x80200000
>> +Loading: #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + ##########################################################
>> + 2.5 MiB/s
>> +done
>> +Bytes transferred = 14939132 (e3f3fc hex)
>> +=> bootm 0x80200000 - 0x82200000
>
> First question: this doc doesn't explain how there is a DT at
> 0x82200000, and what it contains.
>
DT is being passed from the previous stage boot loader to OpenSBI and OpenSBI passed it to U-Boot
after modifying few entries (hart masks and plic entries).
There is a way to provide custom DT in OpenSBI as well.
> Trying this with a freshly build u-boot payload with OpenSBI, bootm
> seems to detect a DT there, but I don't understand how it got there, or
> what it is in it.
>
> Looking a little closer, it appears that this DT (and the address) is
> hard-coded in the OpenSBI code. This should proably be documented here
> for clarity sake.
>
I will update the document to add more clarity.
>> +## Booting kernel from Legacy Image at 80200000 ...
>> + Image Name: Linux
>> + Image Type: RISC-V Linux Kernel Image (uncompressed)
>> + Data Size: 14939068 Bytes = 14.2 MiB
>> + Load Address: 80200000
>> + Entry Point: 80200000
>> + Verifying Checksum ... OK
>> +## Flattened Device Tree blob at 82200000
>> + Booting using the fdt blob at 0x82200000
>> + Loading Kernel Image ... OK
>> + Using Device Tree in place at 0000000082200000, end 0000000082205c69
>> +
>> +Starting kernel ...
>
> Next, I'm able to DHCP and TFTP my uImage just like above, but I don't
> see any output on the console after the "Starting kernel".
>
> That suggests that whatever DT is present there doesn't have the right
> settings for the serial console.
>
> I tried setting the u-boot bootargs to "console=ttySIF0 earlyprintk",
> but I'm still seeing nothing on the console.
>
> Dumping the hard-coded OpenSBI DT from u-boot[1], it seem that the
> chosen node has the right value (as documented in this patch):
>
> Hmm, maybe I'm missing the obvious... is there even an upstream serial
> driver for this UART in v5.0-rc6... (/me goes searching for the
> compatible)... hmm, doesn't look like it.
>
Unfortunately, all the drivers for unleashed are not upstreamed yet. It is a mess and hopefully it will be resolved soon.
>> +[ 0.000000] OF: fdt: Ignoring memory range 0x80000000 - 0x80200000
>> +[ 0.000000] Linux version 5.0.0-rc1-00020-g4b51f736 (atish at jedi-01) (gcc version 7.2.0 (GCC)) #262 SMP Mon Jan 21 17:39:27 PST 2019
>
> Looks like you're testing with a handful of out-of-tree kernel patches.
> Can you give a pointer to where you're building your kernel from?
>
Here is my branch based on 5.0-rc5 that should work.
https://github.com/atishp04/linux/ v5.0-rc5_unleashed_uboot
1-8 patches are mostly SMP fixes and currently under review. They should be part of next merge window.
------------------------------------------------------------------------------------------
1. 4a0edc9b RISC-V: Assign hwcap as per comman capabilities.
2. c29e4afa irqchip/irq-sifive-plic: Check and continue in case of an invalid cpuid.
3. 6c191098 clocksource/drivers/riscv: Add required checks during clock source init
4. d89bfcf6 RISC-V: Compare cpuid with NR_CPUS before mapping.
5. 474cb3e3 RISC-V: Allow hartid-to-cpuid function to fail.
6. 5e07a2f4 RISC-V: Remove NR_CPUs check during hartid search from DT
7. cf5f2ec6 RISC-V: Move cpuid to hartid mapping to SMP.
8. 7838fe36 RISC-V: Do not wait indefinitely in __cpu_up
------------------------------------------------------------------------------------------
The real mess is the following driver patches for unleashed board.
9. d46dc16f spi: sifive: no dma hack
10. e8ea1346 spi: add driver for the SiFive SPI controller
11. 120d5658 pcie-microsemi: added support for the Vera-board root complex
12. afb97b09 RISC-V: Networking fix Hack
13. 4ca6e585 pwm-sifive: add a driver for SiFive SoC PWM
14. ddb4b49e gpio-sifive: support GPIO on SiFive SoCs
15. f8859c7d u54-prci: driver for core U54 clocks
16. 27b6fd77 u54-prci: driver for core U54 clocks
17. dcd33855 gemgxl-mgmt: implement clock switch for GEM tx_clk
18. b25bb020 tty: serial: add driver for the SiFive UART
19. fd6f363f dt-bindings: serial: add documentation for the SiFive UART driver
Please make sure following configs are enabled in your config.
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
I will update the document to mention about the driver patches as well. Sorry for the inconvenience caused.
Regards,
Atish
> I'm guessing at a minimum I at least need the serial driver.
>
> Thanks,
>
> Kevin
>
> [1]
> => fdt addr 0x82200000
> => fdt list
> / {
> #address-cells = <0x00000002>;
> #size-cells = <0x00000002>;
> compatible = "sifive,fu540g", "sifive,fu500";
> model = "sifive,hifive-unleashed-a00";
> aliases {
> };
> chosen {
> };
> firmware {
> };
> cpus {
> };
> memory at 80000000 {
> };
> soc {
> };
> };
> => fdt list /chosen
> chosen {
> stdout-path = "/soc/serial at 10010000:115200";
> };
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot
More information about the U-Boot
mailing list