I've heard from two separate people who have had trouble getting started
with BBL & open-source FSBL test flows with arbitrary DT files on the
Freedom Unleashed board. The following instructions should help get
people started.
The core issue, aside from general unfamiliarity, is that multiple parts
of the pre-kernel software stack try to parse and/or modify the kernel DT.
We wish to avoid this as much as possible.
Testing with U-boot and OpenSBI is currently left as an exercise for the
reader, for a similar reason and because those ports are still quite new.
The following instructions are provided with no warranty whatsoever, and
assume knowledge of the shell and Linux. If implemented carelessly, may
trash your filesystems or do other horrible things.
- Paul
These instructions assume that bare metal and Linux RV64 cross-toolchains
are installed. If not, consider using crosstool-ng with the
"riscv64-unknown-elf" and "riscv64-unknown-linux-gnu" experimental sample
configurations. You will need both.
1. Put the location of the temporary build tree into the BASE
environment variable, and set up some initial directories:
export BASE=~/riscv-test; mkdir -p ${BASE}/work
2. Partition a microSD card with (at least) two GPT partitions.
Here is a sample sfdisk dump:
label: gpt
label-id: 074689DB-0440-411C-91DB-440DFE5BA0B6
device: /dev/sda
unit: sectors
first-lba: 34
last-lba: 62333918
/dev/sda1 : start= 2048, size= 2048, type=5B193300-FC78-40CD-8002-E86C45580B47, uuid=DEAD9378-45FF-44FB-B2E3-F3FEA45ADC9E, name="fsbl"
/dev/sda2 : start= 4096, size= 65536, type=2E54B353-1271-4842-806F-E436D6AF6985, uuid=1B48DE68-8004-444D-BA47-AAA8DBEBFA60, name="bbl"
/dev/sda3 : start= 69632, size= 62264287, type=0FC63DAF-8483-4772-8E79-3D69D8477DE4, uuid=D672F1FC-3E45-4CC1-835A-E6384A26C395, name="rootfs"
3. Download the open-source FSBL:
cd ${BASE}
git clone https://github.com/sifive/freedom-u540-c000-bootloader
4. Build the open-source FSBL:
cd freedom-u540-c000-bootloader
CROSSCOMPILE=/opt/rv64gc-mmu-elf/bin/riscv64-unknown-elf- make
5. Write the open-source FSBL to the first partition of the SD card with
something like:
sudo dd if=fsbl.bin of=/dev/SD-CARD-DEVICE1 conv=nocreat
6. Copy an initramfs sysroot into ${BASE}/work/buildroot_initramfs_sysroot.
A reasonable one to start with is the sysroot built by
freedom-u-sdk, in work/buildroot_initramfs_sysroot.
7. Set the CROSS_COMPILE environment variable to point to your
cross-compiler, in the Linux kernel form:
export CROSS_COMPILE=/opt/rv64gc-mmu-linux-8.2.0/bin/riscv64-unknown-linux-gnu-
8. Put something like this into a script and run it:
if [ ! -d ${BASE} ]; then
echo Base build directory must be set in the BASE environment variable
fi
if [ ! -x ${CROSS_COMPILE}gcc ]; then
echo Path to cross-compiler must be set in the CROSS_COMPILE
environment variable
fi
export ARCH=riscv
export OBJCOPY=${CROSS_COMPILE}objcopy
export CC=${CROSS_COMPILE}gcc
CORES=$(getconf _NPROCESSORS_ONLN)
#
#
cd ${BASE}
git clone -b dev/paulw/reduce-dt-load-v1
https://github.com/sifive/riscv-pk
git clone -b dev/paulw/dts-v5.1-rc6-experimental
https://github.com/sifive/riscv-linux
cd riscv-linux
make -j${CORES} defconfig dtbs vmlinux
${CROSS_COMPILE}strip -o ${BASE}/work/vmlinux-stripped
${BASE}/riscv-linux/vmlinux
rm -rf ${BASE}/work/riscv-pk
mkdir -p ${BASE}/work/riscv-pk
cd ${BASE}/work/riscv-pk
ln -sf
${BASE}/riscv-linux/arch/riscv/boot/dts/sifive/hifive-unleashed-a00-fu540.dtb
${BASE}/riscv-pk/linux.dtb
${BASE}/riscv-pk/configure \
--host=riscv64-unknown-linux-gnu \
--enable-print-device-tree --with-payload=../vmlinux-stripped
CFLAGS="-mabi=lp64d -march=rv64imafdc" make
$OBJCOPY -S -O binary --change-addresses -0x80000000 bbl ../bbl.bin
9. Write ${BASE}/work/bbl.bin to the second partition of your microSD
card with something like:
sudo dd if=${BASE}/work/bbl.bin of=/dev/SD-CARD-DEVICE2 bs=64k conv=nocreat
10. Boot the microSD card on your Unleashed board.
An update for those testing RISC-V patches: here's a new branch of
riscv-pk/bbl that doesn't try to read or modify the DT data at all, which
should be useful until U-Boot settles down. This new riscv-pk version
should be easier to use than the previous version for those testing
upstream-bound kernel DT data on SiFive hardware:
https://github.com/sifive/riscv-pk/tree/dev/paulw/configurable-machine-data-methods-v1
To build a BBL that doesn't touch the DT data, use the
"--with-config-method=hifive_unleashed" switch for the "configure" script.
As before, this version of riscv-pk can take a DTB that can be passed
along to the kernel. But this time the path to the DTB can be specified
on the "configure" script command line.
Below is an example of how to configure it. (The directory structure
should be familiar to those using the v1_0 tag of freedom-u-sdk, with the
kernel source in ./linux, riscv-pk source in ./riscv-pk, and build trees
in work/{linux,riscv-pk}.)
cd work/riscv-pk
CC=/opt/rv64gc-mmu-linux-8.2.0/bin/riscv64-unknown-linux-gnu-gcc ../../riscv-pk/configure \
--host=riscv64-unknown-linux-gnu \
--with-payload=../../work/linux/vmlinux-stripped \
--with-config-method=hifive_unleashed \
--enable-dtb \
--with-dtb-path=../../work/linux/arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dtb
Here is an Linux kernel branch with updated DT data that can be booted
with the above bootloader:
https://github.com/sifive/riscv-linux/tree/dev/paulw/dts-v5.2-rc1-experimental
A sample boot log follows, using a 'defconfig' build from that branch.
- Paul
iFive FSBL: 2019-04-22-1081db9
Using FSBL DTB
HiFive-U serial #: 0000002d
Loading boot payload................................
bbl loader
Relocated DTB from 0000000080007040 to 0000000083200000
[ 0.000000] OF: fdt: Ignoring memory range 0x80000000 - 0x80200000
[ 0.000000] Linux version 5.2.0-rc1-00006-ge4a86563f655 (paulw@viisi) (gcc version 8.2.0 (GCC)) #65 SMP Mon May 27 23:36:33 PDT 2019
[ 0.000000] earlycon: sifive0 at MMIO 0x0000000010010000 (options '')
[ 0.000000] printk: bootconsole [sifive0] enabled
[ 0.000000] printk: debug: ignoring loglevel setting.
[ 0.000000] initrd not found or empty - disabling initrd
[ 0.000000] Zone ranges:
[ 0.000000] DMA32 [mem 0x0000000080200000-0x00000000ffffffff]
[ 0.000000] Normal [mem 0x0000000100000000-0x000000027fffffff]
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000080200000-0x000000027fffffff]
[ 0.000000] Initmem setup node 0 [mem 0x0000000080200000-0x000000027fffffff]
[ 0.000000] On node 0 totalpages: 2096640
[ 0.000000] DMA32 zone: 7161 pages used for memmap
[ 0.000000] DMA32 zone: 0 pages reserved
[ 0.000000] DMA32 zone: 523776 pages, LIFO batch:63
[ 0.000000] Normal zone: 21504 pages used for memmap
[ 0.000000] Normal zone: 1572864 pages, LIFO batch:63
[ 0.000000] software IO TLB: mapped [mem 0xfbfff000-0xfffff000] (64MB)
[ 0.000000] CPU with hartid=0 is not available
[ 0.000000] CPU with hartid=0 is not available
[ 0.000000] elf_hwcap is 0x112d
[ 0.000000] percpu: Embedded 17 pages/cpu s30184 r8192 d31256 u69632
[ 0.000000] pcpu-alloc: s30184 r8192 d31256 u69632 alloc=17*4096
[ 0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 2067975
[ 0.000000] Kernel command line: earlycon=sifive,0x10010000 console=ttySIF0,115200 ignore_loglevel debug root=/dev/ram0
[ 0.000000] Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes)
[ 0.000000] Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes)
[ 0.000000] Sorting __ex_table...
[ 0.000000] Memory: 8178620K/8386560K available (5806K kernel code, 395K rwdata, 1851K rodata, 5853K init, 806K bss, 207940K reserved, 0K cma-reserved)
[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[ 0.000000] rcu: Hierarchical RCU implementation.
[ 0.000000] rcu: RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=4.
[ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
[ 0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4
[ 0.000000] NR_IRQS: 0, nr_irqs: 0, preallocated irqs: 0
[ 0.000000] plic: mapped 53 interrupts with 4 handlers for 9 contexts.
[ 0.000000] riscv_timer_init_dt: Registering clocksource cpuid [0] hartid [3]
[ 0.000000] clocksource: riscv_clocksource: mask: 0xffffffffffffffff max_cycles: 0x1d854df40, max_idle_ns: 3526361616960 ns
[ 0.000006] sched_clock: 64 bits at 1000kHz, resolution 1000ns, wraps every 2199023255500ns
[ 0.008456] Console: colour dummy device 80x25
[ 0.012813] Calibrating delay loop (skipped), value calculated using timer frequency.. 2.00 BogoMIPS (lpj=4000)
[ 0.022841] pid_max: default: 32768 minimum: 301
[ 0.027939] Mount-cache hash table entries: 16384 (order: 5, 131072 bytes)
[ 0.034634] Mountpoint-cache hash table entries: 16384 (order: 5, 131072 bytes)
[ 0.042315] *** VALIDATE proc ***
[ 0.045010] *** VALIDATE cgroup1 ***
[ 0.048462] *** VALIDATE cgroup2 ***
[ 0.053000] rcu: Hierarchical SRCU implementation.
[ 0.057473] smp: Bringing up secondary CPUs ...
[ 0.063256] smp: Brought up 1 node, 4 CPUs
[ 0.068186] devtmpfs: initialized
[ 0.072404] random: get_random_u32 called from bucket_table_alloc.isra.10+0x4e/0x15e with crng_init=0
[ 0.081020] random: get_random_bytes called from setup_net+0x3a/0x1b8 with crng_init=0
[ 0.088974] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
[ 0.098480] futex hash table entries: 1024 (order: 4, 65536 bytes)
[ 0.105299] NET: Registered protocol family 16
[ 0.109683] random: get_random_bytes called from kcmp_cookies_init+0x1c/0x4a with crng_init=0
[ 0.129984] vgaarb: loaded
[ 0.132159] SCSI subsystem initialized
[ 0.135927] libata version 3.00 loaded.
[ 0.139630] usbcore: registered new interface driver usbfs
[ 0.144998] usbcore: registered new interface driver hub
[ 0.150360] usbcore: registered new device driver usb
[ 0.156037] clocksource: Switched to clocksource riscv_clocksource
[ 0.167530] NET: Registered protocol family 2
[ 0.171747] tcp_listen_portaddr_hash hash table entries: 4096 (order: 5, 163840 bytes)
[ 0.179576] TCP established hash table entries: 65536 (order: 7, 524288 bytes)
[ 0.188249] TCP bind hash table entries: 65536 (order: 9, 2097152 bytes)
[ 0.201277] TCP: Hash tables configured (established 65536 bind 65536)
[ 0.207506] UDP hash table entries: 4096 (order: 6, 393216 bytes)
[ 0.214439] UDP-Lite hash table entries: 4096 (order: 6, 393216 bytes)
[ 0.221731] NET: Registered protocol family 1
[ 0.225830] RPC: Registered named UNIX socket transport module.
[ 0.231226] RPC: Registered udp transport module.
[ 0.235906] RPC: Registered tcp transport module.
[ 0.240593] RPC: Registered tcp NFSv4.1 backchannel transport module.
[ 0.247018] PCI: CLS 0 bytes, default 64
[ 0.665279] workingset: timestamp_bits=62 max_order=21 bucket_order=0
[ 0.680212] NFS: Registering the id_resolver key type
[ 0.684561] Key type id_resolver registered
[ 0.688653] Key type id_legacy registered
[ 0.692654] nfs4filelayout_init: NFSv4 File Layout Driver Registering...
[ 0.699720] NET: Registered protocol family 38
[ 0.703819] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254)
[ 0.711145] io scheduler mq-deadline registered
[ 0.715653] io scheduler kyber registered
[ 0.757094] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[ 0.763685] 10010000.serial: ttySIF0 at MMIO 0x10010000 (irq = 4, base_baud = 0) is a SiFive UART v0
[ 0.772072] printk: console [ttySIF0] enabled
[ 0.772072] printk: console [ttySIF0] enabled
[ 0.780723] printk: bootconsole [sifive0] disabled
[ 0.780723] printk: bootconsole [sifive0] disabled
[ 0.790539] 10011000.serial: ttySIF1 at MMIO 0x10011000 (irq = 1, base_baud = 0) is a SiFive UART v0
[ 0.799641] [drm] radeon kernel modesetting enabled.
[ 0.813383] loop: module loaded
[ 0.816227] libphy: Fixed MDIO Bus: probed
[ 0.820345] e1000e: Intel(R) PRO/1000 Network Driver - 3.2.6-k
[ 0.825645] e1000e: Copyright(c) 1999 - 2015 Intel Corporation.
[ 0.831647] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[ 0.838065] ehci-pci: EHCI PCI platform driver
[ 0.842520] ehci-platform: EHCI generic platform driver
[ 0.847757] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[ 0.853865] ohci-pci: OHCI PCI platform driver
[ 0.858329] ohci-platform: OHCI generic platform driver
[ 0.863771] usbcore: registered new interface driver uas
[ 0.868853] usbcore: registered new interface driver usb-storage
[ 0.874961] mousedev: PS/2 mouse device common for all mice
[ 0.880734] usbcore: registered new interface driver usbhid
[ 0.885901] usbhid: USB HID core driver
[ 0.890586] NET: Registered protocol family 10
[ 0.895181] Segment Routing with IPv6
[ 0.898160] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
[ 0.904576] NET: Registered protocol family 17
[ 0.908487] Key type dns_resolver registered
[ 0.913352] Warning: unable to open an initial console.
[ 0.933780] Freeing unused kernel memory: 5852K
[ 0.937543] This architecture does not have kernel memory protection.
[ 0.943960] Run /init as init process
[ 1.531025] random: dd: uninitialized urandom read (512 bytes read)
[ 16.657284] random: dropbear: uninitialized urandom read (32 bytes read)
[ 16.669210] _warn_unseeded_randomness: 11 callbacks suppressed
[ 16.669230] random: get_random_bytes called from tcp_fastopen_init_key_once+0x40/0x58 with crng_init=0
[ 16.686212] random: get_random_bytes called from load_elf_binary+0x7c0/0xca4 with crng_init=0
Welcome to Buildroot
buildroot login:
On Tue 28 May 2019 at 01:32, Paul Walmsley <[email protected]> wrote:
> An update for those testing RISC-V patches: here's a new branch of
> riscv-pk/bbl that doesn't try to read or modify the DT data at all, which
> should be useful until U-Boot settles down. This new riscv-pk version
> should be easier to use than the previous version for those testing
> upstream-bound kernel DT data on SiFive hardware:
>
> https://github.com/sifive/riscv-pk/tree/dev/paulw/configurable-machine-data-methods-v1
>
> To build a BBL that doesn't touch the DT data, use the
> "--with-config-method=hifive_unleashed" switch for the "configure" script.
> As before, this version of riscv-pk can take a DTB that can be passed
> along to the kernel. But this time the path to the DTB can be specified
> on the "configure" script command line.
>
> Below is an example of how to configure it. (The directory structure
> should be familiar to those using the v1_0 tag of freedom-u-sdk, with the
> kernel source in ./linux, riscv-pk source in ./riscv-pk, and build trees
> in work/{linux,riscv-pk}.)
>
> cd work/riscv-pk
> CC=/opt/rv64gc-mmu-linux-8.2.0/bin/riscv64-unknown-linux-gnu-gcc ../../riscv-pk/configure \
> --host=riscv64-unknown-linux-gnu \
> --with-payload=../../work/linux/vmlinux-stripped \
> --with-config-method=hifive_unleashed \
> --enable-dtb \
> --with-dtb-path=../../work/linux/arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dtb
>
>
> Here is an Linux kernel branch with updated DT data that can be booted
> with the above bootloader:
>
> https://github.com/sifive/riscv-linux/tree/dev/paulw/dts-v5.2-rc1-experimental
>
> A sample boot log follows, using a 'defconfig' build from that branch.
Thanks Paul, I can confirm that it works.
Something is still unclear to myself.
Using FSBL + riscv-pk/bbl the linux kernel + device tree boots.
Neither FSBL nor riscv-pk/bbl are modifying the DT.
Using FSBL + OpenSBI + U-Boot the same kernel + device tree hangs on
running /init.
Would you have any pointer on what riscv-pk does that OpenSBI/U-boot doesn't ?
Or maybe it is the other way around - OpenSBI/U-boot does something that
extra that should not happen.
Thanks,
Loys
On Tue, May 28, 2019 at 05:10:42PM +0200, Loys Ollivier wrote:
> On Tue 28 May 2019 at 01:32, Paul Walmsley <[email protected]> wrote:
>
> > An update for those testing RISC-V patches: here's a new branch of
> > riscv-pk/bbl that doesn't try to read or modify the DT data at all, which
> > should be useful until U-Boot settles down.
[...]
> > Here is an Linux kernel branch with updated DT data that can be booted
> > with the above bootloader:
> >
> > https://github.com/sifive/riscv-linux/tree/dev/paulw/dts-v5.2-rc1-experimental
> >
> > A sample boot log follows, using a 'defconfig' build from that branch.
>
> Thanks Paul, I can confirm that it works.
>
> Something is still unclear to myself.
> Using FSBL + riscv-pk/bbl the linux kernel + device tree boots.
> Neither FSBL nor riscv-pk/bbl are modifying the DT.
>
> Using FSBL + OpenSBI + U-Boot the same kernel + device tree hangs on
> running /init.
>
> Would you have any pointer on what riscv-pk does that OpenSBI/U-boot doesn't ?
> Or maybe it is the other way around - OpenSBI/U-boot does something that
> extra that should not happen.
Hello,
I don't know which version of OpenSBI you are using, but there is
a problem with the combination of kernel 5.2-rc1 and OpenSBI
versions before commit
https://github.com/riscv/opensbi/commit/4e2cd478208531c47343290f15b577d40c82649c
that can result in a hang on executing init, so in case you
should be using an older OpenSBI build that might be the source
of the problem that you are experiencing.
Regards,
Karsten
--
Ich widerspreche hiermit ausdrücklich der Nutzung sowie der
Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung
sowie der Markt- oder Meinungsforschung.
> On 5/28/19 1:33 AM, Paul Walmsley wrote:
> An update for those testing RISC-V patches: here's a new branch of
> riscv-pk/bbl that doesn't try to read or modify the DT data at all, which
> should be useful until U-Boot settles down. This new riscv-pk version
> should be easier to use than the previous version for those testing
> upstream-bound kernel DT data on SiFive hardware:
> https://github.com/sifive/riscv-pk/tree/dev/paulw/configurable-machine-data-methods-v1
> To build a BBL that doesn't touch the DT data, use the
> "--with-config-method=hifive_unleashed" switch for the "configure" script.
> As before, this version of riscv-pk can take a DTB that can be passed
> along to the kernel. But this time the path to the DTB can be specified
> on the "configure" script command line.
> Below is an example of how to configure it. (The directory structure
> should be familiar to those using the v1_0 tag of freedom-u-sdk, with the
> kernel source in ./linux, riscv-pk source in ./riscv-pk, and build trees
> in work/{linux,riscv-pk}.)
> cd work/riscv-pk
> CC=/opt/rv64gc-mmu-linux-8.2.0/bin/riscv64-unknown-linux-gnu-gcc ../../riscv-pk/configure \
> --host=riscv64-unknown-linux-gnu \
> --with-payload=../../work/linux/vmlinux-stripped \
> --with-config-method=hifive_unleashed \
> --enable-dtb \
> --with-dtb-path=../../work/linux/arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dtb
> Here is an Linux kernel branch with updated DT data that can be booted
> with the above bootloader:
> https://github.com/sifive/riscv-linux/tree/dev/paulw/dts-v5.2-rc1-experimental
Hi Paul,
I see your branch has the DT where the hart0 is marked disabled and M-mode interrupts are masked in PLIC DT entry. IIRC, your v1 patch series for DT didn't have those fixes.
I am assuming that you are planning to upstream these changes as well and it will be part of your v2 patch. Is that correct ?
> A sample boot log follows, using a 'defconfig' build from that branch.
> - Paul
> iFive FSBL: 2019-04-22-1081db9
> Using FSBL DTB
> HiFive-U serial #: 0000002d
> Loading boot payload................................
> bbl loader
> Relocated DTB from 0000000080007040 to 0000000083200000
> [ 0.000000] OF: fdt: Ignoring memory range 0x80000000 - 0x80200000
> [ 0.000000] Linux version 5.2.0-rc1-00006-ge4a86563f655 (paulw@viisi) (gcc version 8.2.0 (GCC)) #65 SMP Mon May 27 23:36:33 PDT 2019
> [ 0.000000] earlycon: sifive0 at MMIO 0x0000000010010000 (options '')
> [ 0.000000] printk: bootconsole [sifive0] enabled
> [ 0.000000] printk: debug: ignoring loglevel setting.
> [ 0.000000] initrd not found or empty - disabling initrd
> [ 0.000000] Zone ranges:
> [ 0.000000] DMA32 [mem 0x0000000080200000-0x00000000ffffffff]
> [ 0.000000] Normal [mem 0x0000000100000000-0x000000027fffffff]
> [ 0.000000] Movable zone start for each node
> [ 0.000000] Early memory node ranges
> [ 0.000000] node 0: [mem 0x0000000080200000-0x000000027fffffff]
> [ 0.000000] Initmem setup node 0 [mem 0x0000000080200000-0x000000027fffffff]
> [ 0.000000] On node 0 totalpages: 2096640
> [ 0.000000] DMA32 zone: 7161 pages used for memmap
> [ 0.000000] DMA32 zone: 0 pages reserved
> [ 0.000000] DMA32 zone: 523776 pages, LIFO batch:63
> [ 0.000000] Normal zone: 21504 pages used for memmap
> [ 0.000000] Normal zone: 1572864 pages, LIFO batch:63
> [ 0.000000] software IO TLB: mapped [mem 0xfbfff000-0xfffff000] (64MB)
> [ 0.000000] CPU with hartid=0 is not available
> [ 0.000000] CPU with hartid=0 is not available
> [ 0.000000] elf_hwcap is 0x112d
> [ 0.000000] percpu: Embedded 17 pages/cpu s30184 r8192 d31256 u69632
> [ 0.000000] pcpu-alloc: s30184 r8192 d31256 u69632 alloc=17*4096
> [ 0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
> [ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 2067975
> [ 0.000000] Kernel command line: earlycon=sifive,0x10010000 console=ttySIF0,115200 ignore_loglevel debug root=/dev/ram0
> [ 0.000000] Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes)
> [ 0.000000] Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes)
> [ 0.000000] Sorting __ex_table...
> [ 0.000000] Memory: 8178620K/8386560K available (5806K kernel code, 395K rwdata, 1851K rodata, 5853K init, 806K bss, 207940K reserved, 0K cma-reserved)
> [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
> [ 0.000000] rcu: Hierarchical RCU implementation.
> [ 0.000000] rcu: RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=4.
> [ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
> [ 0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4
> [ 0.000000] NR_IRQS: 0, nr_irqs: 0, preallocated irqs: 0
> [ 0.000000] plic: mapped 53 interrupts with 4 handlers for 9 contexts.
> [ 0.000000] riscv_timer_init_dt: Registering clocksource cpuid [0] hartid [3]
> [ 0.000000] clocksource: riscv_clocksource: mask: 0xffffffffffffffff max_cycles: 0x1d854df40, max_idle_ns: 3526361616960 ns
> [ 0.000006] sched_clock: 64 bits at 1000kHz, resolution 1000ns, wraps every 2199023255500ns
> [ 0.008456] Console: colour dummy device 80x25
> [ 0.012813] Calibrating delay loop (skipped), value calculated using timer frequency.. 2.00 BogoMIPS (lpj=4000)
> [ 0.022841] pid_max: default: 32768 minimum: 301
> [ 0.027939] Mount-cache hash table entries: 16384 (order: 5, 131072 bytes)
> [ 0.034634] Mountpoint-cache hash table entries: 16384 (order: 5, 131072 bytes)
> [ 0.042315] *** VALIDATE proc ***
> [ 0.045010] *** VALIDATE cgroup1 ***
> [ 0.048462] *** VALIDATE cgroup2 ***
> [ 0.053000] rcu: Hierarchical SRCU implementation.
> [ 0.057473] smp: Bringing up secondary CPUs ...
> [ 0.063256] smp: Brought up 1 node, 4 CPUs
> [ 0.068186] devtmpfs: initialized
> [ 0.072404] random: get_random_u32 called from bucket_table_alloc.isra.10+0x4e/0x15e with crng_init=0
> [ 0.081020] random: get_random_bytes called from setup_net+0x3a/0x1b8 with crng_init=0
> [ 0.088974] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
> [ 0.098480] futex hash table entries: 1024 (order: 4, 65536 bytes)
> [ 0.105299] NET: Registered protocol family 16
> [ 0.109683] random: get_random_bytes called from kcmp_cookies_init+0x1c/0x4a with crng_init=0
> [ 0.129984] vgaarb: loaded
> [ 0.132159] SCSI subsystem initialized
> [ 0.135927] libata version 3.00 loaded.
> [ 0.139630] usbcore: registered new interface driver usbfs
> [ 0.144998] usbcore: registered new interface driver hub
> [ 0.150360] usbcore: registered new device driver usb
> [ 0.156037] clocksource: Switched to clocksource riscv_clocksource
> [ 0.167530] NET: Registered protocol family 2
> [ 0.171747] tcp_listen_portaddr_hash hash table entries: 4096 (order: 5, 163840 bytes)
> [ 0.179576] TCP established hash table entries: 65536 (order: 7, 524288 bytes)
> [ 0.188249] TCP bind hash table entries: 65536 (order: 9, 2097152 bytes)
> [ 0.201277] TCP: Hash tables configured (established 65536 bind 65536)
> [ 0.207506] UDP hash table entries: 4096 (order: 6, 393216 bytes)
> [ 0.214439] UDP-Lite hash table entries: 4096 (order: 6, 393216 bytes)
> [ 0.221731] NET: Registered protocol family 1
> [ 0.225830] RPC: Registered named UNIX socket transport module.
> [ 0.231226] RPC: Registered udp transport module.
> [ 0.235906] RPC: Registered tcp transport module.
> [ 0.240593] RPC: Registered tcp NFSv4.1 backchannel transport module.
> [ 0.247018] PCI: CLS 0 bytes, default 64
> [ 0.665279] workingset: timestamp_bits=62 max_order=21 bucket_order=0
> [ 0.680212] NFS: Registering the id_resolver key type
> [ 0.684561] Key type id_resolver registered
> [ 0.688653] Key type id_legacy registered
> [ 0.692654] nfs4filelayout_init: NFSv4 File Layout Driver Registering...
> [ 0.699720] NET: Registered protocol family 38
> [ 0.703819] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254)
> [ 0.711145] io scheduler mq-deadline registered
> [ 0.715653] io scheduler kyber registered
> [ 0.757094] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
> [ 0.763685] 10010000.serial: ttySIF0 at MMIO 0x10010000 (irq = 4, base_baud = 0) is a SiFive UART v0
> [ 0.772072] printk: console [ttySIF0] enabled
> [ 0.772072] printk: console [ttySIF0] enabled
> [ 0.780723] printk: bootconsole [sifive0] disabled
> [ 0.780723] printk: bootconsole [sifive0] disabled
> [ 0.790539] 10011000.serial: ttySIF1 at MMIO 0x10011000 (irq = 1, base_baud = 0) is a SiFive UART v0
> [ 0.799641] [drm] radeon kernel modesetting enabled.
> [ 0.813383] loop: module loaded
> [ 0.816227] libphy: Fixed MDIO Bus: probed
> [ 0.820345] e1000e: Intel(R) PRO/1000 Network Driver - 3.2.6-k
> [ 0.825645] e1000e: Copyright(c) 1999 - 2015 Intel Corporation.
> [ 0.831647] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
> [ 0.838065] ehci-pci: EHCI PCI platform driver
> [ 0.842520] ehci-platform: EHCI generic platform driver
> [ 0.847757] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
> [ 0.853865] ohci-pci: OHCI PCI platform driver
> [ 0.858329] ohci-platform: OHCI generic platform driver
> [ 0.863771] usbcore: registered new interface driver uas
> [ 0.868853] usbcore: registered new interface driver usb-storage
> [ 0.874961] mousedev: PS/2 mouse device common for all mice
> [ 0.880734] usbcore: registered new interface driver usbhid
> [ 0.885901] usbhid: USB HID core driver
> [ 0.890586] NET: Registered protocol family 10
> [ 0.895181] Segment Routing with IPv6
> [ 0.898160] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
> [ 0.904576] NET: Registered protocol family 17
> [ 0.908487] Key type dns_resolver registered
> [ 0.913352] Warning: unable to open an initial console.
> [ 0.933780] Freeing unused kernel memory: 5852K
> [ 0.937543] This architecture does not have kernel memory protection.
> [ 0.943960] Run /init as init process
> [ 1.531025] random: dd: uninitialized urandom read (512 bytes read)
> [ 16.657284] random: dropbear: uninitialized urandom read (32 bytes read)
> [ 16.669210] _warn_unseeded_randomness: 11 callbacks suppressed
> [ 16.669230] random: get_random_bytes called from tcp_fastopen_init_key_once+0x40/0x58 with crng_init=0
> [ 16.686212] random: get_random_bytes called from load_elf_binary+0x7c0/0xca4 with crng_init=0
> Welcome to Buildroot
> buildroot login:
> _______________________________________________
> linux-riscv mailing list
> [email protected]
> http://lists.infradead.org/mailman/listinfo/linux-riscv
--
Regards,
Atish
On 5/28/19 8:36 AM, Karsten Merker wrote:
> On Tue, May 28, 2019 at 05:10:42PM +0200, Loys Ollivier wrote:
>> On Tue 28 May 2019 at 01:32, Paul Walmsley <[email protected]> wrote:
>>
>>> An update for those testing RISC-V patches: here's a new branch of
>>> riscv-pk/bbl that doesn't try to read or modify the DT data at all, which
>>> should be useful until U-Boot settles down.
> [...]
>>> Here is an Linux kernel branch with updated DT data that can be booted
>>> with the above bootloader:
>>>
>>> https://github.com/sifive/riscv-linux/tree/dev/paulw/dts-v5.2-rc1-experimental
>>>
>>> A sample boot log follows, using a 'defconfig' build from that branch.
>>
>> Thanks Paul, I can confirm that it works.
>>
>> Something is still unclear to myself.
>> Using FSBL + riscv-pk/bbl the linux kernel + device tree boots.
>> Neither FSBL nor riscv-pk/bbl are modifying the DT.
>>
>> Using FSBL + OpenSBI + U-Boot the same kernel + device tree hangs on
>> running /init.
>>
>> Would you have any pointer on what riscv-pk does that OpenSBI/U-boot doesn't ?
>> Or maybe it is the other way around - OpenSBI/U-boot does something that
>> extra that should not happen.
>
> Hello,
>
> I don't know which version of OpenSBI you are using, but there is
> a problem with the combination of kernel 5.2-rc1 and OpenSBI
> versions before commit
>
> https://github.com/riscv/opensbi/commit/4e2cd478208531c47343290f15b577d40c82649c
>
> that can result in a hang on executing init, so in case you
> should be using an older OpenSBI build that might be the source
> of the problem that you are experiencing.
>
> Regards,
> Karsten
>
I verified the updated DT with upstream kernel for the boot flow OpenSBI
+ U-Boot + Linux or OpenSBI + Linux.
OpenSBI should be compiled for sifive platform with following additional
argument
FW_PAYLOAD_FDT_PATH=<linux kernel
source>/arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dtb
FYI: It will only work when kernel is given a payload to U-Boot/OpenSBI
directly.
Network booting is still not working as the clock driver probe doesn't
happen because of the updated DT.
--
Regards,
Atish
On Tue 28 May 2019 at 17:35, Karsten Merker <[email protected]> wrote:
> On Tue, May 28, 2019 at 05:10:42PM +0200, Loys Ollivier wrote:
>> On Tue 28 May 2019 at 01:32, Paul Walmsley <[email protected]> wrote:
>>
>> > An update for those testing RISC-V patches: here's a new branch of
>> > riscv-pk/bbl that doesn't try to read or modify the DT data at all, which
>> > should be useful until U-Boot settles down.
> [...]
>> > Here is an Linux kernel branch with updated DT data that can be booted
>> > with the above bootloader:
>> >
>> > https://github.com/sifive/riscv-linux/tree/dev/paulw/dts-v5.2-rc1-experimental
>> >
>> > A sample boot log follows, using a 'defconfig' build from that branch.
>>
>> Thanks Paul, I can confirm that it works.
>>
>> Something is still unclear to myself.
>> Using FSBL + riscv-pk/bbl the linux kernel + device tree boots.
>> Neither FSBL nor riscv-pk/bbl are modifying the DT.
>>
>> Using FSBL + OpenSBI + U-Boot the same kernel + device tree hangs on
>> running /init.
>>
>> Would you have any pointer on what riscv-pk does that OpenSBI/U-boot doesn't ?
>> Or maybe it is the other way around - OpenSBI/U-boot does something that
>> extra that should not happen.
>
> Hello,
>
> I don't know which version of OpenSBI you are using, but there is
> a problem with the combination of kernel 5.2-rc1 and OpenSBI
> versions before commit
>
> https://github.com/riscv/opensbi/commit/4e2cd478208531c47343290f15b577d40c82649c
>
> that can result in a hang on executing init, so in case you
> should be using an older OpenSBI build that might be the source
> of the problem that you are experiencing.
>
Hello Karsten,
That was it ! This fixes the issue I had on init execution.
Good catch, thanks a lot for the help !
Regards,
Loys
> Regards,
> Karsten
> --
> Ich widerspreche hiermit ausdrücklich der Nutzung sowie der
> Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung
> sowie der Markt- oder Meinungsforschung.
On Wed 29 May 2019 at 00:50, Atish Patra <[email protected]> wrote:
> On 5/28/19 8:36 AM, Karsten Merker wrote:
>> On Tue, May 28, 2019 at 05:10:42PM +0200, Loys Ollivier wrote:
>>> On Tue 28 May 2019 at 01:32, Paul Walmsley <[email protected]> wrote:
>>>
>>>> An update for those testing RISC-V patches: here's a new branch of
>>>> riscv-pk/bbl that doesn't try to read or modify the DT data at all, which
>>>> should be useful until U-Boot settles down.
>> [...]
>>>> Here is an Linux kernel branch with updated DT data that can be booted
>>>> with the above bootloader:
>>>>
>>>> https://github.com/sifive/riscv-linux/tree/dev/paulw/dts-v5.2-rc1-experimental
>>>>
>>>> A sample boot log follows, using a 'defconfig' build from that branch.
>>>
>>> Thanks Paul, I can confirm that it works.
>>>
>>> Something is still unclear to myself.
>>> Using FSBL + riscv-pk/bbl the linux kernel + device tree boots.
>>> Neither FSBL nor riscv-pk/bbl are modifying the DT.
>>>
>>> Using FSBL + OpenSBI + U-Boot the same kernel + device tree hangs on
>>> running /init.
>>>
>>> Would you have any pointer on what riscv-pk does that OpenSBI/U-boot doesn't ?
>>> Or maybe it is the other way around - OpenSBI/U-boot does something that
>>> extra that should not happen.
>>
>> Hello,
>>
>> I don't know which version of OpenSBI you are using, but there is
>> a problem with the combination of kernel 5.2-rc1 and OpenSBI
>> versions before commit
>>
>> https://github.com/riscv/opensbi/commit/4e2cd478208531c47343290f15b577d40c82649c
>>
>> that can result in a hang on executing init, so in case you
>> should be using an older OpenSBI build that might be the source
>> of the problem that you are experiencing.
>>
>> Regards,
>> Karsten
>>
>
> I verified the updated DT with upstream kernel for the boot flow OpenSBI
> + U-Boot + Linux or OpenSBI + Linux.
>
> OpenSBI should be compiled for sifive platform with following additional
> argument
>
> FW_PAYLOAD_FDT_PATH=<linux kernel
> source>/arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dtb
>
> FYI: It will only work when kernel is given a payload to U-Boot/OpenSBI
> directly.
>
Hum, I am surprised by this statement.
I was able to verify the latest DT patch serie from Paul with:
OpenSBI + U-Boot + Linux & DT.
Following the OpenSBI documentation [0] with U-Boot payload:
FW_PAYLOAD_PATH=<u-boot_build_dir>/u-boot.bin
I get an U-Boot prompt and then I can just load the linux kernel and
device tree from the network.
[0]: https://github.com/riscv/opensbi/blob/master/docs/platform/sifive_fu540.md#building-sifive-fu540-platform
> Network booting is still not working as the clock driver probe doesn't
> happen because of the updated DT.
>
> --
> Regards,
> Atish
On 5/29/19 3:04 AM, Loys Ollivier wrote:
> On Wed 29 May 2019 at 00:50, Atish Patra <[email protected]> wrote:
>
>> On 5/28/19 8:36 AM, Karsten Merker wrote:
>>> On Tue, May 28, 2019 at 05:10:42PM +0200, Loys Ollivier wrote:
>>>> On Tue 28 May 2019 at 01:32, Paul Walmsley <[email protected]> wrote:
>>>>
>>>>> An update for those testing RISC-V patches: here's a new branch of
>>>>> riscv-pk/bbl that doesn't try to read or modify the DT data at all, which
>>>>> should be useful until U-Boot settles down.
>>> [...]
>>>>> Here is an Linux kernel branch with updated DT data that can be booted
>>>>> with the above bootloader:
>>>>>
>>>>> https://github.com/sifive/riscv-linux/tree/dev/paulw/dts-v5.2-rc1-experimental
>>>>>
>>>>> A sample boot log follows, using a 'defconfig' build from that branch.
>>>>
>>>> Thanks Paul, I can confirm that it works.
>>>>
>>>> Something is still unclear to myself.
>>>> Using FSBL + riscv-pk/bbl the linux kernel + device tree boots.
>>>> Neither FSBL nor riscv-pk/bbl are modifying the DT.
>>>>
>>>> Using FSBL + OpenSBI + U-Boot the same kernel + device tree hangs on
>>>> running /init.
>>>>
>>>> Would you have any pointer on what riscv-pk does that OpenSBI/U-boot doesn't ?
>>>> Or maybe it is the other way around - OpenSBI/U-boot does something that
>>>> extra that should not happen.
>>>
>>> Hello,
>>>
>>> I don't know which version of OpenSBI you are using, but there is
>>> a problem with the combination of kernel 5.2-rc1 and OpenSBI
>>> versions before commit
>>>
>>> https://github.com/riscv/opensbi/commit/4e2cd478208531c47343290f15b577d40c82649c
>>>
>>> that can result in a hang on executing init, so in case you
>>> should be using an older OpenSBI build that might be the source
>>> of the problem that you are experiencing.
>>>
>>> Regards,
>>> Karsten
>>>
>>
>> I verified the updated DT with upstream kernel for the boot flow OpenSBI
>> + U-Boot + Linux or OpenSBI + Linux.
>>
>> OpenSBI should be compiled for sifive platform with following additional
>> argument
>>
>> FW_PAYLOAD_FDT_PATH=<linux kernel
>> source>/arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dtb
>>
>> FYI: It will only work when kernel is given a payload to U-Boot/OpenSBI
>> directly.
>>
>
> Hum, I am surprised by this statement.
That's because U-Boot also using the new DT. With FW_PAYLOAD_FDT_PATH,
OpenSBI ignores the DT from FSBL and U-Boot gets the updated DT from
OpenSBI.
> I was able to verify the latest DT patch serie from Paul with:
> OpenSBI + U-Boot + Linux & DT.
>
> Following the OpenSBI documentation [0] with U-Boot payload:
> FW_PAYLOAD_PATH=<u-boot_build_dir>/u-boot.bin
>
> I get an U-Boot prompt and then I can just load the linux kernel and
> device tree from the network.
>
Cool. This approach will also work where DT is loaded separately after
U-Boot is booted.
> [0]: https://github.com/riscv/opensbi/blob/master/docs/platform/sifive_fu540.md#building-sifive-fu540-platform
>
>> Network booting is still not working as the clock driver probe doesn't
>> happen because of the updated DT.
>>
>> --
>> Regards,
>> Atish
>
--
Regards,
Atish
> On May 29, 2019, at 5:04 AM, Loys Ollivier <[email protected]> wrote:
>
> On Wed 29 May 2019 at 00:50, Atish Patra <[email protected]> wrote:
>
>> On 5/28/19 8:36 AM, Karsten Merker wrote:
>>> On Tue, May 28, 2019 at 05:10:42PM +0200, Loys Ollivier wrote:
>>>> On Tue 28 May 2019 at 01:32, Paul Walmsley <[email protected]> wrote:
>>>>
>>>>> An update for those testing RISC-V patches: here's a new branch of
>>>>> riscv-pk/bbl that doesn't try to read or modify the DT data at all, which
>>>>> should be useful until U-Boot settles down.
>>> [...]
>>>>> Here is an Linux kernel branch with updated DT data that can be booted
>>>>> with the above bootloader:
>>>>>
>>>>> https://github.com/sifive/riscv-linux/tree/dev/paulw/dts-v5.2-rc1-experimental
>>>>>
>>>>> A sample boot log follows, using a 'defconfig' build from that branch.
>>>>
>>>> Thanks Paul, I can confirm that it works.
>>>>
>>>> Something is still unclear to myself.
>>>> Using FSBL + riscv-pk/bbl the linux kernel + device tree boots.
>>>> Neither FSBL nor riscv-pk/bbl are modifying the DT.
>>>>
>>>> Using FSBL + OpenSBI + U-Boot the same kernel + device tree hangs on
>>>> running /init.
>>>>
>>>> Would you have any pointer on what riscv-pk does that OpenSBI/U-boot doesn't ?
>>>> Or maybe it is the other way around - OpenSBI/U-boot does something that
>>>> extra that should not happen.
>>>
>>> Hello,
>>>
>>> I don't know which version of OpenSBI you are using, but there is
>>> a problem with the combination of kernel 5.2-rc1 and OpenSBI
>>> versions before commit
>>>
>>> https://github.com/riscv/opensbi/commit/4e2cd478208531c47343290f15b577d40c82649c
>>>
>>> that can result in a hang on executing init, so in case you
>>> should be using an older OpenSBI build that might be the source
>>> of the problem that you are experiencing.
>>>
>>> Regards,
>>> Karsten
>>>
>>
>> I verified the updated DT with upstream kernel for the boot flow OpenSBI
>> + U-Boot + Linux or OpenSBI + Linux.
>>
>> OpenSBI should be compiled for sifive platform with following additional
>> argument
>>
>> FW_PAYLOAD_FDT_PATH=<linux kernel
>> source>/arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dtb
>>
>> FYI: It will only work when kernel is given a payload to U-Boot/OpenSBI
>> directly.
>>
>
> Hum, I am surprised by this statement.
> I was able to verify the latest DT patch serie from Paul with:
> OpenSBI + U-Boot + Linux & DT.
>
> Following the OpenSBI documentation [0] with U-Boot payload:
> FW_PAYLOAD_PATH=<u-boot_build_dir>/u-boot.bin
>
> I get an U-Boot prompt and then I can just load the linux kernel and
> device tree from the network.
>
> [0]: https://github.com/riscv/opensbi/blob/master/docs/platform/sifive_fu540.md#building-sifive-fu540-platform
>
Could you confirm which git hash of U-boot you are building, and that the .config matches
the defconfig (or send me the .config you used)?
I’d like to get everything that’s working integrated in one place into a freedom-u-sdk test branch.
>> Network booting is still not working as the clock driver probe doesn't
>> happen because of the updated DT.
>>
>> --
>> Regards,
>> Atish
>
> _______________________________________________
> linux-riscv mailing list
> [email protected]
> http://lists.infradead.org/mailman/listinfo/linux-riscv
On Wed 29 May 2019 at 12:25, Troy Benjegerdes <[email protected]> wrote:
>> On May 29, 2019, at 5:04 AM, Loys Ollivier <[email protected]> wrote:
>>
>> On Wed 29 May 2019 at 00:50, Atish Patra <[email protected]> wrote:
>>
>>> On 5/28/19 8:36 AM, Karsten Merker wrote:
>>>> On Tue, May 28, 2019 at 05:10:42PM +0200, Loys Ollivier wrote:
>>>>> On Tue 28 May 2019 at 01:32, Paul Walmsley <[email protected]> wrote:
>>>>>
>>>>>> An update for those testing RISC-V patches: here's a new branch of
>>>>>> riscv-pk/bbl that doesn't try to read or modify the DT data at all, which
>>>>>> should be useful until U-Boot settles down.
>>>> [...]
>>>>>> Here is an Linux kernel branch with updated DT data that can be booted
>>>>>> with the above bootloader:
>>>>>>
>>>>>> https://github.com/sifive/riscv-linux/tree/dev/paulw/dts-v5.2-rc1-experimental
>>>>>>
>>>>>> A sample boot log follows, using a 'defconfig' build from that branch.
>>>>>
>>>>> Thanks Paul, I can confirm that it works.
>>>>>
>>>>> Something is still unclear to myself.
>>>>> Using FSBL + riscv-pk/bbl the linux kernel + device tree boots.
>>>>> Neither FSBL nor riscv-pk/bbl are modifying the DT.
>>>>>
>>>>> Using FSBL + OpenSBI + U-Boot the same kernel + device tree hangs on
>>>>> running /init.
>>>>>
>>>>> Would you have any pointer on what riscv-pk does that OpenSBI/U-boot doesn't ?
>>>>> Or maybe it is the other way around - OpenSBI/U-boot does something that
>>>>> extra that should not happen.
>>>>
>>>> Hello,
>>>>
>>>> I don't know which version of OpenSBI you are using, but there is
>>>> a problem with the combination of kernel 5.2-rc1 and OpenSBI
>>>> versions before commit
>>>>
>>>> https://github.com/riscv/opensbi/commit/4e2cd478208531c47343290f15b577d40c82649c
>>>>
>>>> that can result in a hang on executing init, so in case you
>>>> should be using an older OpenSBI build that might be the source
>>>> of the problem that you are experiencing.
>>>>
>>>> Regards,
>>>> Karsten
>>>>
>>>
>>> I verified the updated DT with upstream kernel for the boot flow OpenSBI
>>> + U-Boot + Linux or OpenSBI + Linux.
>>>
>>> OpenSBI should be compiled for sifive platform with following additional
>>> argument
>>>
>>> FW_PAYLOAD_FDT_PATH=<linux kernel
>>> source>/arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dtb
>>>
>>> FYI: It will only work when kernel is given a payload to U-Boot/OpenSBI
>>> directly.
>>>
>>
>> Hum, I am surprised by this statement.
>> I was able to verify the latest DT patch serie from Paul with:
>> OpenSBI + U-Boot + Linux & DT.
>>
>> Following the OpenSBI documentation [0] with U-Boot payload:
>> FW_PAYLOAD_PATH=<u-boot_build_dir>/u-boot.bin
>>
>> I get an U-Boot prompt and then I can just load the linux kernel and
>> device tree from the network.
>>
>> [0]: https://github.com/riscv/opensbi/blob/master/docs/platform/sifive_fu540.md#building-sifive-fu540-platform
>>
>
> Could you confirm which git hash of U-boot you are building, and that the .config matches
> the defconfig (or send me the .config you used)?
Sure,
OpenSBI: a6395acd6cb2c35871481d3e4f0beaf449f8c0fd
U-Boot: (origin/master) 344a0e4367d0820b8eb2ea4a90132433e038095f
Kernel: from Paul from this thread [1]
I use the sifive_fu540_defconfig of U-Boot with no additional changes.
[1] https://github.com/sifive/riscv-linux/tree/dev/paulw/dts-v5.2-rc1-experimental
>
> I’d like to get everything that’s working integrated in one place into a freedom-u-sdk test branch.
>
>
Let me know the test branch when it's up :)
Loys
>>> Network booting is still not working as the clock driver probe doesn't
>>> happen because of the updated DT.
>>>
>>> --
>>> Regards,
>>> Atish
>>
>> _______________________________________________
>> linux-riscv mailing list
>> [email protected]
>> http://lists.infradead.org/mailman/listinfo/linux-riscv
> On Jun 3, 2019, at 4:49 AM, Loys Ollivier <[email protected]> wrote:
>
> On Wed 29 May 2019 at 12:25, Troy Benjegerdes <[email protected]> wrote:
>
>>> On May 29, 2019, at 5:04 AM, Loys Ollivier <[email protected]> wrote:
>>>
>>> On Wed 29 May 2019 at 00:50, Atish Patra <[email protected]> wrote:
>>>
>>>> On 5/28/19 8:36 AM, Karsten Merker wrote:
>>>>> On Tue, May 28, 2019 at 05:10:42PM +0200, Loys Ollivier wrote:
>>>>>> On Tue 28 May 2019 at 01:32, Paul Walmsley <[email protected]> wrote:
>>>>>>
>>>>>>> An update for those testing RISC-V patches: here's a new branch of
>>>>>>> riscv-pk/bbl that doesn't try to read or modify the DT data at all, which
>>>>>>> should be useful until U-Boot settles down.
>>>>> [...]
>>>>>>> Here is an Linux kernel branch with updated DT data that can be booted
>>>>>>> with the above bootloader:
>>>>>>>
>>>>>>> https://github.com/sifive/riscv-linux/tree/dev/paulw/dts-v5.2-rc1-experimental
>>>>>>>
>>>>>>> A sample boot log follows, using a 'defconfig' build from that branch.
>>>>>>
>>>>>> Thanks Paul, I can confirm that it works.
>>>>>>
>>>>>> Something is still unclear to myself.
>>>>>> Using FSBL + riscv-pk/bbl the linux kernel + device tree boots.
>>>>>> Neither FSBL nor riscv-pk/bbl are modifying the DT.
>>>>>>
>>>>>> Using FSBL + OpenSBI + U-Boot the same kernel + device tree hangs on
>>>>>> running /init.
>>>>>>
>>>>>> Would you have any pointer on what riscv-pk does that OpenSBI/U-boot doesn't ?
>>>>>> Or maybe it is the other way around - OpenSBI/U-boot does something that
>>>>>> extra that should not happen.
>>>>>
>>>>> Hello,
>>>>>
>>>>> I don't know which version of OpenSBI you are using, but there is
>>>>> a problem with the combination of kernel 5.2-rc1 and OpenSBI
>>>>> versions before commit
>>>>>
>>>>> https://github.com/riscv/opensbi/commit/4e2cd478208531c47343290f15b577d40c82649c
>>>>>
>>>>> that can result in a hang on executing init, so in case you
>>>>> should be using an older OpenSBI build that might be the source
>>>>> of the problem that you are experiencing.
>>>>>
>>>>> Regards,
>>>>> Karsten
>>>>>
>>>>
>>>> I verified the updated DT with upstream kernel for the boot flow OpenSBI
>>>> + U-Boot + Linux or OpenSBI + Linux.
>>>>
>>>> OpenSBI should be compiled for sifive platform with following additional
>>>> argument
>>>>
>>>> FW_PAYLOAD_FDT_PATH=<linux kernel
>>>> source>/arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dtb
>>>>
>>>> FYI: It will only work when kernel is given a payload to U-Boot/OpenSBI
>>>> directly.
>>>>
>>>
>>> Hum, I am surprised by this statement.
>>> I was able to verify the latest DT patch serie from Paul with:
>>> OpenSBI + U-Boot + Linux & DT.
>>>
>>> Following the OpenSBI documentation [0] with U-Boot payload:
>>> FW_PAYLOAD_PATH=<u-boot_build_dir>/u-boot.bin
>>>
>>> I get an U-Boot prompt and then I can just load the linux kernel and
>>> device tree from the network.
>>>
>>> [0]: https://github.com/riscv/opensbi/blob/master/docs/platform/sifive_fu540.md#building-sifive-fu540-platform
>>>
>>
>> Could you confirm which git hash of U-boot you are building, and that the .config matches
>> the defconfig (or send me the .config you used)?
>
> Sure,
>
> OpenSBI: a6395acd6cb2c35871481d3e4f0beaf449f8c0fd
> U-Boot: (origin/master) 344a0e4367d0820b8eb2ea4a90132433e038095f
> Kernel: from Paul from this thread [1]
>
> I use the sifive_fu540_defconfig of U-Boot with no additional changes.
>
> [1] https://github.com/sifive/riscv-linux/tree/dev/paulw/dts-v5.2-rc1-experimental
>
>>
>> I’d like to get everything that’s working integrated in one place into a freedom-u-sdk test branch.
>>
>>
>
> Let me know the test branch when it's up :)
>
> Loys
>
Have a look at https://github.com/tmagik/freedom-u-sdk/tree/dev/u-boot
I need to fill in the makefiles (and set up our lab TFTP server) so
‘make test’ builds and runs everything.
The first time I tried I got an endless string of exceptions, and how I get this:
OpenSBI v0.3 (Jun 3 2019 08:04:44)
____ _____ ____ _____
/ __ \ / ____| _ \_ _|
| | | |_ __ ___ _ __ | (___ | |_) || |
| | | | '_ \ / _ \ '_ \ \___ \| _ < | |
| |__| | |_) | __/ | | |____) | |_) || |_
\____/| .__/ \___|_| |_|_____/|____/_____|
| |
|_|
Platform Name : SiFive Freedom U540
Platform HART Features : RV64ACDFIMSU
Platform Max HARTs : 5
Current Hart : 4
Firmware Base : 0x80000000
Firmware Size : 92 KB
Runtime SBI Version : 0.1
PMP0: 0x0000000080000000-0x000000008001ffff (A)
PMP1: 0x0000000000000000-0x0000007fffffffff (A,R,W,X)
U-Boot 2019.07-rc3-00047-ga8a796e (Jun 03 2019 - 07:54:59 -0700)
CPU: rv64imafdc
Model: sifive,hifive-unleashed-a00
DRAM: 8 GiB
In: serial@10010000
Out: serial@10010000
Err: serial@10010000
Net:
>>>> Network booting is still not working as the clock driver probe doesn't
>>>> happen because of the updated DT.
>>>>
>>>> --
>>>> Regards,
>>>> Atish
>>>
>>> _______________________________________________
>>> linux-riscv mailing list
>>> [email protected]
>>> http://lists.infradead.org/mailman/listinfo/linux-riscv
> On Jun 3, 2019, at 4:49 AM, Loys Ollivier <[email protected]> wrote:
>
> On Wed 29 May 2019 at 12:25, Troy Benjegerdes <[email protected]> wrote:
>
>>> On May 29, 2019, at 5:04 AM, Loys Ollivier <[email protected]> wrote:
>>>
>>> On Wed 29 May 2019 at 00:50, Atish Patra <[email protected]> wrote:
>>>
>>>> On 5/28/19 8:36 AM, Karsten Merker wrote:
>>>>> On Tue, May 28, 2019 at 05:10:42PM +0200, Loys Ollivier wrote:
>>>>>> On Tue 28 May 2019 at 01:32, Paul Walmsley <[email protected]> wrote:
>>>>>>
>>>>>>> An update for those testing RISC-V patches: here's a new branch of
>>>>>>> riscv-pk/bbl that doesn't try to read or modify the DT data at all, which
>>>>>>> should be useful until U-Boot settles down.
>>>>> [...]
>>>>>>> Here is an Linux kernel branch with updated DT data that can be booted
>>>>>>> with the above bootloader:
>>>>>>>
>>>>>>> https://github.com/sifive/riscv-linux/tree/dev/paulw/dts-v5.2-rc1-experimental
>>>>>>>
>>>>>>> A sample boot log follows, using a 'defconfig' build from that branch.
>>>>>>
>>>>>> Thanks Paul, I can confirm that it works.
>>>>>>
>>>>>> Something is still unclear to myself.
>>>>>> Using FSBL + riscv-pk/bbl the linux kernel + device tree boots.
>>>>>> Neither FSBL nor riscv-pk/bbl are modifying the DT.
>>>>>>
>>>>>> Using FSBL + OpenSBI + U-Boot the same kernel + device tree hangs on
>>>>>> running /init.
>>>>>>
>>>>>> Would you have any pointer on what riscv-pk does that OpenSBI/U-boot doesn't ?
>>>>>> Or maybe it is the other way around - OpenSBI/U-boot does something that
>>>>>> extra that should not happen.
>>>>>
>>>>> Hello,
>>>>>
>>>>> I don't know which version of OpenSBI you are using, but there is
>>>>> a problem with the combination of kernel 5.2-rc1 and OpenSBI
>>>>> versions before commit
>>>>>
>>>>> https://github.com/riscv/opensbi/commit/4e2cd478208531c47343290f15b577d40c82649c
>>>>>
>>>>> that can result in a hang on executing init, so in case you
>>>>> should be using an older OpenSBI build that might be the source
>>>>> of the problem that you are experiencing.
>>>>>
>>>>> Regards,
>>>>> Karsten
>>>>>
>>>>
>>>> I verified the updated DT with upstream kernel for the boot flow OpenSBI
>>>> + U-Boot + Linux or OpenSBI + Linux.
>>>>
>>>> OpenSBI should be compiled for sifive platform with following additional
>>>> argument
>>>>
>>>> FW_PAYLOAD_FDT_PATH=<linux kernel
>>>> source>/arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dtb
>>>>
>>>> FYI: It will only work when kernel is given a payload to U-Boot/OpenSBI
>>>> directly.
>>>>
>>>
>>> Hum, I am surprised by this statement.
>>> I was able to verify the latest DT patch serie from Paul with:
>>> OpenSBI + U-Boot + Linux & DT.
>>>
>>> Following the OpenSBI documentation [0] with U-Boot payload:
>>> FW_PAYLOAD_PATH=<u-boot_build_dir>/u-boot.bin
>>>
>>> I get an U-Boot prompt and then I can just load the linux kernel and
>>> device tree from the network.
>>>
>>> [0]: https://github.com/riscv/opensbi/blob/master/docs/platform/sifive_fu540.md#building-sifive-fu540-platform
>>>
>>
>> Could you confirm which git hash of U-boot you are building, and that the .config matches
>> the defconfig (or send me the .config you used)?
>
> Sure,
>
> OpenSBI: a6395acd6cb2c35871481d3e4f0beaf449f8c0fd
> U-Boot: (origin/master) 344a0e4367d0820b8eb2ea4a90132433e038095f
> Kernel: from Paul from this thread [1]
>
> I use the sifive_fu540_defconfig of U-Boot with no additional changes.
>
> [1] https://github.com/sifive/riscv-linux/tree/dev/paulw/dts-v5.2-rc1-experimental
>
>>
>> I’d like to get everything that’s working integrated in one place into a freedom-u-sdk test branch.
>>
>>
>
> Let me know the test branch when it's up :)
>
> Loys
Please take a look at https://github.com/tmagik/freedom-u-sdk/tree/functional_test
When I booted the original 4.19 vmlinux.bin, I got this:
Booting kernel in
2
1
0
## Starting application at 0x80200000 ...
[ 0.000000] Linux version 4.19.0-sifive-1+ (troyb@epsilon09) (gcc version 8.3.0 (Buildroot 29
[ 0.000000] bootconsole [early0] enabled
With the 5.2 kernel, I get know output, which I assume is expected behavior using the
current DTS provided by the S-mode Uboot.
Booting kernel in
2
1
0
## Starting application at 0x80200000 ...
On Tue, Jun 4, 2019 at 1:47 AM Troy Benjegerdes
<[email protected]> wrote:
>
>
>
> > On Jun 3, 2019, at 4:49 AM, Loys Ollivier <[email protected]> wrote:
> >
> > On Wed 29 May 2019 at 12:25, Troy Benjegerdes <[email protected]> wrote:
> >
> >>> On May 29, 2019, at 5:04 AM, Loys Ollivier <[email protected]> wrote:
> >>>
> >>> On Wed 29 May 2019 at 00:50, Atish Patra <[email protected]> wrote:
> >>>
> >>>> On 5/28/19 8:36 AM, Karsten Merker wrote:
> >>>>> On Tue, May 28, 2019 at 05:10:42PM +0200, Loys Ollivier wrote:
> >>>>>> On Tue 28 May 2019 at 01:32, Paul Walmsley <[email protected]> wrote:
> >>>>>>
> >>>>>>> An update for those testing RISC-V patches: here's a new branch of
> >>>>>>> riscv-pk/bbl that doesn't try to read or modify the DT data at all, which
> >>>>>>> should be useful until U-Boot settles down.
> >>>>> [...]
> >>>>>>> Here is an Linux kernel branch with updated DT data that can be booted
> >>>>>>> with the above bootloader:
> >>>>>>>
> >>>>>>> https://github.com/sifive/riscv-linux/tree/dev/paulw/dts-v5.2-rc1-experimental
> >>>>>>>
> >>>>>>> A sample boot log follows, using a 'defconfig' build from that branch.
> >>>>>>
> >>>>>> Thanks Paul, I can confirm that it works.
> >>>>>>
> >>>>>> Something is still unclear to myself.
> >>>>>> Using FSBL + riscv-pk/bbl the linux kernel + device tree boots.
> >>>>>> Neither FSBL nor riscv-pk/bbl are modifying the DT.
> >>>>>>
> >>>>>> Using FSBL + OpenSBI + U-Boot the same kernel + device tree hangs on
> >>>>>> running /init.
> >>>>>>
> >>>>>> Would you have any pointer on what riscv-pk does that OpenSBI/U-boot doesn't ?
> >>>>>> Or maybe it is the other way around - OpenSBI/U-boot does something that
> >>>>>> extra that should not happen.
> >>>>>
> >>>>> Hello,
> >>>>>
> >>>>> I don't know which version of OpenSBI you are using, but there is
> >>>>> a problem with the combination of kernel 5.2-rc1 and OpenSBI
> >>>>> versions before commit
> >>>>>
> >>>>> https://github.com/riscv/opensbi/commit/4e2cd478208531c47343290f15b577d40c82649c
> >>>>>
> >>>>> that can result in a hang on executing init, so in case you
> >>>>> should be using an older OpenSBI build that might be the source
> >>>>> of the problem that you are experiencing.
> >>>>>
> >>>>> Regards,
> >>>>> Karsten
> >>>>>
> >>>>
> >>>> I verified the updated DT with upstream kernel for the boot flow OpenSBI
> >>>> + U-Boot + Linux or OpenSBI + Linux.
> >>>>
> >>>> OpenSBI should be compiled for sifive platform with following additional
> >>>> argument
> >>>>
> >>>> FW_PAYLOAD_FDT_PATH=<linux kernel
> >>>> source>/arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dtb
> >>>>
> >>>> FYI: It will only work when kernel is given a payload to U-Boot/OpenSBI
> >>>> directly.
> >>>>
> >>>
> >>> Hum, I am surprised by this statement.
> >>> I was able to verify the latest DT patch serie from Paul with:
> >>> OpenSBI + U-Boot + Linux & DT.
> >>>
> >>> Following the OpenSBI documentation [0] with U-Boot payload:
> >>> FW_PAYLOAD_PATH=<u-boot_build_dir>/u-boot.bin
> >>>
> >>> I get an U-Boot prompt and then I can just load the linux kernel and
> >>> device tree from the network.
> >>>
> >>> [0]: https://github.com/riscv/opensbi/blob/master/docs/platform/sifive_fu540.md#building-sifive-fu540-platform
> >>>
> >>
> >> Could you confirm which git hash of U-boot you are building, and that the .config matches
> >> the defconfig (or send me the .config you used)?
> >
> > Sure,
> >
> > OpenSBI: a6395acd6cb2c35871481d3e4f0beaf449f8c0fd
> > U-Boot: (origin/master) 344a0e4367d0820b8eb2ea4a90132433e038095f
> > Kernel: from Paul from this thread [1]
> >
> > I use the sifive_fu540_defconfig of U-Boot with no additional changes.
> >
> > [1] https://github.com/sifive/riscv-linux/tree/dev/paulw/dts-v5.2-rc1-experimental
> >
> >>
> >> I’d like to get everything that’s working integrated in one place into a freedom-u-sdk test branch.
> >>
> >>
> >
> > Let me know the test branch when it's up :)
> >
> > Loys
>
> Please take a look at https://github.com/tmagik/freedom-u-sdk/tree/functional_test
>
> When I booted the original 4.19 vmlinux.bin, I got this:
>
> Booting kernel in
> 2
> 1
> 0
> ## Starting application at 0x80200000 ...
> [ 0.000000] Linux version 4.19.0-sifive-1+ (troyb@epsilon09) (gcc version 8.3.0 (Buildroot 29
> [ 0.000000] bootconsole [early0] enabled
>
> With the 5.2 kernel, I get know output, which I assume is expected behavior using the
> current DTS provided by the S-mode Uboot.
>
> Booting kernel in
> 2
> 1
> 0
> ## Starting application at 0x80200000 ...
The earlyprintk support has been removed from latest kernel. Instead of
earlyprintk we now use generic earlycon support.
To use earlycon, just add "earlycon=sbi" parameter in your kernel bootargs.
On U-Boot, kernel bootargs can be changed by changing "bootargs" U-Boot
environment variable.
Regards,
Anup