On 2/13/19 1:52 AM, Auer, Lukas wrote:
On Wed, 2019-02-13 at 01:31 +0000, Atish Patra wrote:
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.
[...]
+=> 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@10090000: PHY present at 0
+ethernet@10090000: Starting autonegotiation...
+ethernet@10090000: Autonegotiation complete
+ethernet@10090000: link up, 1000Mbps full-duplex (lpa: 0x3800)
+Using ethernet@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.
FYI, you can also use the fdtcontroladdr environment variable to pass
U-Boot's device tree, so the one passed by OpenSBI, to Linux.
Thanks,
Lukas
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.
FYI: earlyprintk is disabled in v5.0rc5 in favor of earlycon.
so you need to use
CONFIG_CMDLINE="earlycon=sbi console=ttySIF0"
Regards,
Atish
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.
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@80000000 {
};
soc {
};
};
=> fdt list /chosen
chosen {
stdout-path = "/soc/serial@10010000:115200";
};
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
