Atish Patra <atish.pa...@wdc.com> writes:

>> On Feb 12, 2019, at 4:18 PM, Kevin Hilman <khil...@baylibre.com> wrote:
>> 
>> Anup Patel <anup.pa...@wdc.com> writes:
>> 
>>> From: Atish Patra <atish.pa...@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.pa...@wdc.com>
>>> Signed-off-by: Anup Patel <anup.pa...@wdc.com>
>>> Reviewed-by: Lukas Auer <lukas.a...@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. 
>

[...]

>> 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.

And if u-boot were load (or TFTP) a custom DT, this should work too,
right?

>> 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.

Thanks.

>>> +## 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@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.

Yes, building a kernel from there, using the config options you
mentioned works.  Thanks.

> 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.

Probably should mention the kernel config requirements too, if they are
not the defaults in upstream.

Kevin

_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Reply via email to